token续期必须在每次合法请求时触发，不能依赖前端定时刷新或php原生session自动延长；核心是在认证中间件中校验通过后动态生成新jwt、更新redis中token状态并删除旧键，同时通过响应头x-auth-token推送新token供前端更新。
Token续期必须在每次合法请求时触发，不是靠前端定时刷新
ThinkPHP 的 session_start() 默认不会自动延长会话有效期，单纯依赖 PHP 原生 session 机制会导致 Token 过期后用户突然登出。安全续期的核心逻辑是：只要用户本次请求通过身份校验（如 JWT 解析成功、或数据库 token 匹配有效），就生成新 Token 并更新过期时间，同时旧 Token 失效（防重放）。
- 不要在中间件里无条件调用
Session::set()或写死ini_set('session.gc_maxlifetime', ...)—— 这会延长所有会话，破坏时效性控制 - 推荐把续期逻辑放在登录态校验中间件中，且仅对非登录接口（如
/api/user/profile）生效；登录接口本身不续期，避免循环刷新 - 若使用 JWT，
exp字段必须每次动态计算（如time() + 3600），不能复用原始 payload
用 Redis 存储 Token 并设置滑动过期时间
PHP 原生 file session 不适合 Token 续期场景：无法原子性地“读旧值 → 判有效性 → 写新值 → 删旧值”。Redis 是更稳妥的选择，配合 SETEX 和 DEL 操作可精确控制生命周期。
- Token 键名建议为
token:{user_id}:{device_fingerprint}，避免同一账号多端互踢时误删 - 续期时先用
GET检查原 Token 是否存在且未被标记为失效（可用哈希字段status标记invalid） - 新 Token 写入用
SETEX token:{new_id} 7200 {jwt_string}，7200 秒是滑动窗口上限，实际每次续期都重置 TTL - 务必在写入新 Token 后立即
DEL旧键，否则存在短暂双 Token 窗口，增加重放风险
ThinkPHP 中间件里如何安全执行续期
在 app/middleware/CheckAuth.php 中，完成校验后插入续期动作，而不是在控制器里做——否则容易遗漏或重复执行。
- 从请求头取
Authorization，提取 Bearer 后的 token 字符串，用JWT::parse($token)验签并检查exp和nbf - 验证通过后调用自定义方法
$this->renewToken($userId, $deviceFp)，该方法生成新 JWT、存入 Redis、返回新 token 字符串 - 用
Response::header('X-Auth-Token', $newToken)推送新 Token 到响应头，前端需监听该 header 并覆盖本地存储 - 禁止直接修改
$_SESSION或调用Session::id()—— ThinkPHP 的 Session 封装与 Token 续期无关，混用会导致状态混乱
前端必须配合处理响应头中的新 Token
很多团队只改后端，结果续期形同虚设：前端仍发送旧 Token，服务端虽生成了新 Token 却无人接收。
- Axios 全局响应拦截器里检查
response.headers['x-auth-token']，存在则更新本地localStorage.setItem('token', ...) - 注意：如果前端用
credentials: 'include'发送 Cookie，而服务端又同时写入 Session，会造成认证凭据冗余甚至冲突，建议统一走 Header Token - 首次请求无
X-Auth-Token头是正常的；但连续两次请求都没收到新头，就要排查中间件是否跳过了续期逻辑（比如游客路由未进 CheckAuth）
滑动过期真正起效的前提，是前后端对 Token 生命周期的理解一致——后端不主动踢人，前端不缓存过期值，Redis 键的 TTL 才有意义。任何一环断开，所谓的“自动续期”就只是个后台日志里的空转操作。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
