ThinkPHP如何做前端Token刷新_ThinkPHP无感续期认证机制【方法】-ThinkPHP-PHP中文网

token过期后前端直接401因后端认证中间件未放行续期路径，需将续期逻辑前置、手动解析token、实现redis黑名单、前端加刷新锁并原子化更新本地token。

thinkphp如何做前端token刷新_thinkphp无感续期认证机制【方法】

Token过期后前端请求直接401，不走续期逻辑

核心原因是 ThinkPHP 的中间件或验证层在解析 Authorization 头时，一发现 token 签名失效或时间过期，就立刻返回 401，根本没机会进续期分支。这不是前端“没发刷新请求”，而是后端压根没给它这个机会。

确保续期逻辑写在认证中间件之前（比如自定义 CheckTokenMiddleware），且对特定路径（如 /api/auth/refresh）放行
不要在 Auth::check() 或 Auth::user() 里隐式触发校验——它们默认严格验签+时效，应改用 Auth::guard()->setToken($token)->user() 手动解析，跳过自动拦截
前端必须带原始 token（非刷新后的新 token）发起刷新请求，后端靠 jwt.refresh 或自定义逻辑识别该请求并生成新 token

ThinkPHP JWT 续期时刷新 token 但旧 token 仍能用

这是典型的状态管理缺失：JWT 默认无状态，服务端不存 token 黑名单，只要签名有效、未过期，就一直认。所谓“刷新”，只是发个新 token，旧的还在有效期里照样通行。

前端设计优化skill

前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。

下载

必须配合黑名单机制：刷新成功后，把旧 token 的 jti 和过期时间存入 Redis，键名为 blacklist:<jti></jti>，TTL 设为原 token 剩余有效期
每次解析 token 前，先查 Cache::has('blacklist:'.$jti)，命中则直接抛出 TokenBlacklistedException
别依赖 jwt.refresh 自带的黑名单（tp-jwt 包的实现常有 bug 或未启用），手动控制更可靠

前端无感续期时并发请求导致重复刷新或 401 爆发

用户快速点击多个按钮，或页面加载触发多个 API，都可能同时携带即将过期的 token 发起请求。若每个请求都各自尝试刷新，轻则重复写 Redis，重则因竞态导致部分请求拿不到新 token 而失败。

前端需加刷新锁：用一个 Promise 缓存正在执行的刷新请求，后续请求 await 同一个 Promise，避免多次调用
后端刷新接口必须幂等：同一旧 token 多次请求，应始终返回相同新 token（可缓存 refresh_token:<old_jti></old_jti> 5 秒，避免重复生成）
不要让所有请求都走刷新流程——只对返回 401 Expired 的响应做判断，且需检查响应头中是否含 X-Need-Refresh: true 这类明确标识

tp6.1+ 使用 think-auth 或 jwt-auth 包时 refresh 接口 404 或报错 Class not found

常见于包未正确注册路由或服务提供者，尤其是手动安装而非 composer require 引入时，配置漏掉关键环节。

确认已执行 php think vendor:publish --force（如果用了 topthink/think-auth）或按 firebase/php-jwt + 自定义逻辑方式实现，而非强依赖某个未维护的第三方 jwt 包
刷新路由必须显式定义，例如：Route::post('auth/refresh', 'AuthController@refresh')->middleware('cors');，不能指望包自动注册
若用 Auth::guard('api')，确保 config/auth.php 中 'api' guard 的 provider 和 driver 配置正确，否则 Auth::guard()->refresh() 会找不到方法