token过期时间设置无效的核心原因是exp声明未真实写入payload或验证端未启用时间校验。thinkphp依赖firebase/php-jwt，其decode默认校验exp，但前提是payload含合法整型时间戳且调用完整、密钥一致、系统时间准确。
Token过期时间设置无效，核心原因不是配置没写，而是exp声明未真正写入payload，或验证端未启用时间校验逻辑。ThinkPHP本身不处理JWT，靠第三方库（如 firebase/php-jwt）解析，而该库只在 decode 时自动检查 exp——前提是 exp 字段存在且为合法整型时间戳。
检查 exp 是否真实写入载荷
JWT 的过期完全依赖 payload 中的 exp 字段（秒级 UNIX 时间戳）。很多开发者误以为设了 config 或传了 expiresIn 就生效，但 ThinkPHP 没有内置 sign 方法，必须手动构造 payload。
- 生成 token 时，务必显式计算并赋值：
$payload['exp'] = time() + 3600;（不能用 date('U')、Carbon::now()->timestamp 不加秒数转换等易错写法） - 确认 payload 数组中 确实包含 'exp' => int 值，可用
dump($payload)在签发前打印验证 - 避免使用字符串时间（如 "1 hour"）、毫秒时间戳（JS 的 Date.now() 直接传入会超大）或 null/0 值
确认验证端调用 decode 时启用自动时间检查
firebase/php-jwt 的 JWT::decode() 默认会校验 exp、nbf、iat，但前提是：你没关掉它，也没绕过它。
- 不要手动解码后忽略异常，例如写
try { $decoded = JWT::decode(...) } catch (Exception $e) { return $decoded; }—— 这会让 ExpiredException 被吞掉 - 确保 decode 调用完整：传入密钥、指定算法（如
['HS256']），不传空算法数组 - 若中间件里用了
JWT::parse()或只取 header/payload 未签名验证，那根本没走 exp 校验流程
排查环境与配置干扰项
即使代码正确，以下常见问题也会导致“看似没过期却报401”或“明明过期却不拦截”：
-
服务器时间不准：用
date命令检查系统时间，误差超过 leeway（默认 0 秒）就会失败；可在 decode 时加容差：JWT::decode($token, $key, ['HS256'], ['leeway' => 60]) -
密钥不一致：签发用的 $key 和 decode 用的 $key 必须完全相同（包括空格、换行、BOM）；建议统一从
config('jwt.secret')读取 - 缓存或代理干扰：Nginx 或 CDN 缓存了旧 token 响应；前端可能复用已失效 token 并未刷新 Authorization header
推荐标准化配置方式
把过期时长从硬编码抽到配置，既清晰又易维护：
- 在
config/jwt.php中定义：'access_expire' => 7200（2小时，单位秒） - 生成时：
$payload['exp'] = time() + Config::get('jwt.access_expire'); - 验证时不做任何修改，信赖 JWT 库原生 exp 检查逻辑
- 配合 Redis 吊销（如登出删 jti）可补足“提前失效”需求，但不影响 exp 基础机制
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
