TP6接口Token鉴权失败主因是JWT验证链路中断，需依次排查密钥/算法一致性、中间件注册与执行、请求头规范性、时间偏差及Redis并发误判等环节。
TP6接口Token鉴权失败，常见于JWT验证不通过、签名错误、过期或中间件未生效等情况。核心不是换库或重写逻辑，而是找准验证链路上哪一环断了——生成、传输、校验、删除，缺一不可。
检查JWT配置与密钥一致性
鉴权失败的第一排查点是密钥和算法是否严格匹配：
- 确认 jwt.php 配置中的
algo（如 HS256） 与生成 Token 时使用的算法完全一致，大小写、拼写都不能错 -
secret 密钥必须前后端/服务端完全相同，尤其注意环境变量（
JWT_SECRET）是否在当前运行环境正确加载，避免本地有值而线上为空 - 若使用非对称加密（RS256），确保
public_key和private_key路径可读，且内容格式为 PEM（含-----BEGIN RSA PRIVATE KEY-----等头尾） - 检查
ttl（如 86400）是否合理，过短会导致前端刚拿到就失效；leeway建议设为 60，容错网络时间偏差
验证中间件是否真正拦截并执行
很多失败不是Token本身问题，而是中间件根本没跑起来：
- 确认中间件已注册到
app/middleware.php，且位置靠前（优先于 Auth、Session 等依赖用户态的中间件） - 检查路由是否命中该中间件：例如用
Route::group(['middleware' => 'checkToken'], function () { ... })，不能只在控制器里手动调用验证方法 - 调试时可在中间件
handle()开头加Log::info('token middleware triggered')，看日志是否输出 - 注意中间件返回
Json响应时，需显式设置状态码（如return json(['code'=>401])->code(401)），否则可能被框架转成 200
抓取真实请求，比对签名与载荷
Token 失效常因前端传参不规范或服务端解析出错：
- 前端必须将 Token 放在 Header 中，格式为
Authorization: Bearer xxx，注意 Bearer 后有一个空格，且不能有多余换行或不可见字符 - 用 Postman 或 curl 手动构造请求，对比服务端接收到的
$request->header('authorization')是否完整、是否被 Nginx/Apache 截断（常见于未配置underscores_in_headers on） - 在验证逻辑中打印解码后的 payload：
JWT::decode($token, new Key($key, $algo))，观察exp、iat、nbf是否符合预期，特别是服务器时间是否比客户端快/慢太多 - 若用自定义 header 字段（如
X-Token），需在中间件中主动读取，并确保 CORS 配置已显式允许该字段（Access-Control-Allow-Headers）
幂等与并发场景下的Token误判
部分“鉴权失败”实为重复提交导致的 Token 提前失效：
- 若使用 Redis 存储黑名单或一次性 Token，务必用 Lua 脚本原子执行「判断存在 + 删除」，避免两个请求同时读到 token 有效后都放行
- Token key 命名建议带业务前缀，如
"auth:token:".$uid，防止多端登录互相踢出或误删 - 对于支付回调、异步任务等入口，也要接入同一套 Token 校验逻辑，不能只保护用户主动发起的 API
- 临时调试可关闭黑名单机制，仅做签名校验，确认基础流程通后再叠加防重逻辑
