refreshtoken什么时候会失效

refreshToken 失效是保障用户会话安全的重要机制，其失效场景可分为 主动失效（系统或用户触发）和 被动失效（自然过期或异常情况），具体如下：

一、自然过期（被动失效）

这是最常见的失效原因，由 refreshToken 自身的生命周期决定：

• 后端在生成 refreshToken 时会设置 过期时间（通常远长于 accessToken，如7天、30天），一旦超过该时间，令牌自动失效。
• 目的：避免 refreshToken 长期有效带来的安全风险（即使泄露，有效期也有限）。

二、主动失效（系统或用户触发）

1. 用户主动登出

   • 用户点击“退出登录”时，前端会调用后端的“登出接口”，后端会将当前 refreshToken 加入“黑名单”，使其立即失效。
   • 同时前端清除本地存储的 refreshToken，双重保障。

2. 密码修改或账号信息变更

   • 当用户修改密码、手机号等核心信息时，后端为安全起见，会使所有关联的 refreshToken 失效（防止旧令牌被滥用）。

3. 管理员操作

   • 管理员在后台执行“强制下线”“禁用账号”等操作时，目标账号的所有 refreshToken 会被批量失效。

三、异常场景导致的失效（被动失效）

1. 令牌被篡改或伪造

   • 若 refreshToken 在传输或存储过程中被篡改，后端验证签名失败时，会判定为无效令牌。

2. 多设备登录冲突

   • 部分系统限制“单账号同时登录”，当用户在新设备登录时，旧设备的 refreshToken 会被后端主动失效（避免账号共享）。

3. 安全策略触发

   • 后端检测到异常行为（如异地登录、短时间多次刷新令牌失败），可能会临时失效 refreshToken，并要求用户重新验证（如输入验证码）。

4. 令牌存储损坏

   • 前端存储的 refreshToken 因浏览器清理缓存、本地存储损坏等原因丢失或不完整，也会导致其“逻辑失效”（无法正常使用）。

四、与 accessToken 失效的核心区别

维度	accessToken 失效	refreshToken 失效
频率	高频（如2小时）	低频（如7天）
影响范围	仅当前接口请求失败，可通过 refreshToken 刷新	会话无法延续，需重新登录
失效后处理	自动用 refreshToken 换新车票	必须重新登录获取新令牌

总结

refreshToken 失效是 安全与用户体验平衡 的结果：既通过自然过期限制长期风险，又通过主动失效应对用户操作或异常场景。理解这些场景有助于在前端更好地处理令牌失效逻辑（如及时引导登录、避免无效请求）。