Sa-Token 中 Token 自动续期与 Cookie 写入的实践指南

问题背景

在使用 Sa-Token 进行会话管理时，开发者经常会遇到 Token 自动续期的需求。一个典型场景是：用户登录后，每次访问接口时自动延长 Token 的有效期，以保持用户会话活跃。然而，在实际实现中，开发者可能会发现虽然后端成功续期了 Token，但浏览器端的 Cookie 却没有同步更新有效期。

技术原理分析

Sa-Token 的 Token 续期机制涉及两个关键部分：

1. 后端存储续期：通过 StpUtil.renewTimeout() 方法更新存储在服务端的 Token 有效期
2. Cookie 同步更新：Sa-Token 会自动将新的有效期写入响应头的 Set-Cookie

在底层实现上，Sa-Token 的 StpLogic 类会在续期操作后调用 setTokenValueToCookie() 方法，尝试将新的 Token 信息写入 Cookie。

问题根源

通过分析用户提供的代码，问题出在拦截器的执行时机选择上。用户最初在 postHandle 方法中执行续期操作，这导致了 Cookie 写入失败。原因在于：

• Spring MVC 的拦截器链中，postHandle 执行时响应头可能已经确定
• Cookie 写入需要在响应头最终确定前完成
• preHandle 是更合适的执行时机，此时响应处理尚未开始

解决方案

正确的实现方式是将 Token 续期逻辑放在拦截器的 preHandle 方法中：

@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
    if (!StpUtil.isLogin()) {
        return true;
    }
    
    StpUtil.renewTimeout(SaManager.getConfig().getTimeout());
    return true;
}

这种实现确保了：

1. 在请求处理前完成续期操作
2. Sa-Token 有足够的时间将新 Cookie 写入响应
3. 保持了无感刷新的用户体验

最佳实践建议

1. 拦截器选择：对于 Token 续期这类操作，优先使用 preHandle 而非 postHandle
2. 配置检查：确保 Sa-Token 的 Cookie 配置正确，特别是 domain 和 path 设置
3. 测试验证：通过浏览器开发者工具检查响应头中的 Set-Cookie 是否包含更新后的过期时间
4. 安全考虑：合理设置 Token 的 timeout 值，避免过长的会话持续时间带来安全风险

总结

Sa-Token 提供了完善的 Token 管理机制，但开发者需要理解其与 Spring MVC 生命周期的交互方式。通过选择正确的拦截时机，可以确保 Token 续期操作既更新了服务端存储，又同步了客户端 Cookie，实现真正的无感刷新体验。这一实践不仅适用于 Sa-Token，对于其他类似的认证框架也具有参考价值。