javascript 中的 session 本身不直接管理令牌刷新，需前后端协同实现无感刷新：后端采用双令牌机制（access+refresh token），refresh token 通过 httponly cookie 安全传输，前端用拦截器统一处理 401 并重试请求，防重复刷新，session 可绑定 refresh token 实现可撤销与限流。
JavaScript 中的 Session 本身不直接管理令牌刷新，它依赖后端会话机制（如 Cookie + Session ID）配合 JWT 或 OAuth2 的访问令牌（Access Token）实现无感刷新。所谓“无感”，是指用户无感知、不中断操作，后台自动完成令牌续期。关键不在前端 JS 单独做 session，而在于前后端协同设计刷新逻辑。
后端需支持双令牌机制（Access + Refresh Token）
这是无感刷新的基础。Access Token 短期有效（如 15 分钟），Refresh Token 长期有效（如 7 天）、安全存储（HttpOnly Cookie）、仅用于换取新 Access Token。
- 登录成功后，后端下发 Access Token（可放响应体）和 Refresh Token（必须设为 HttpOnly、Secure、SameSite=Strict 的 Cookie）
- 前端 JS 无法读取 HttpOnly Cookie，但浏览器会在后续请求中自动携带它，供后端验证并刷新令牌
- 当 Access Token 过期时，前端发请求到 /refresh 接口（不带 Authorization header），后端校验 Refresh Token 合法性，签发新 Access Token 返回
前端用拦截器统一处理 401 并触发刷新
避免每个 API 调用都手动判断过期，推荐用 Axios 或 Fetch 拦截器集中处理。
- 拦截响应：遇到 401（且非登录/刷新接口），暂停当前请求队列，先调用 /refresh
- 刷新成功后，用新 Access Token 重发原请求；失败则跳转登录页
- 注意防重复刷新：用 Promise 缓存刷新请求，同一时间只发起一次 /refresh
Access Token 存本地存储要谨慎
若必须存 Access Token 在前端（如 localStorage），务必配合其他防护措施：
- Token 不含敏感信息，签名密钥由后端严格保管
- 前端每次请求手动添加 Authorization: Bearer xxx，而非依赖 Cookie
- 刷新成功后立即更新 localStorage 中的 Access Token
- 监听页面卸载事件，在退出前清空 token（但无法防 DevTools 直接读取）
Session 保持与刷新 Token 的协同点
如果后端用传统服务端 Session（如 Express-session），Refresh Token 可绑定 Session ID：
- 用户登录时创建 Session，将 Refresh Token 哈希后存入 Session 数据（或 Redis）
- /refresh 接口校验 HttpOnly Cookie 中的 session_id，再查对应 Refresh Token 是否有效、未被撤销
- 刷新成功后更新 Session 中的 Access Token 有效期，或仅更新 Refresh Token 使用次数/时间戳
- 用户登出时，后端销毁 Session 并清除 Refresh Token 记录，实现真正失效
不复杂但容易忽略细节：Refresh Token 必须可撤销、有使用次数限制、绑定设备/IP（可选），且 /refresh 接口要限流防爆破。前端只需专注拦截与重试逻辑，真正的安全边界在后端。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
