jwt时间验证失败的根源是php运行时时间上下文错误：exp/nbf等字段必须为utc秒级时间戳，而date.timezone配置不当、系统时钟偏差超5分钟、未用key对象传参或docker时区不一致，均会导致expiredexception或beforevalidexception。
Composer本身不校验JWT，出问题的其实是下游PHP库
Composer只是包管理器，它不参与JWT解析或时间验证。所谓“时区不一致导致Token失效”，真实场景是：你用composer require firebase/php-jwt装了JWT库，但PHP脚本里调用JWT::decode()时抛ExpiredException或BeforeValidException——错误根源不在Composer，而在PHP运行时的时间上下文。
- PHP默认用
date.timezone配置的时区解析时间戳，而JWT标准要求所有时间字段（exp、nbf、iat）都是UTC秒级时间戳 - 如果你的
php.ini里设了date.timezone = "Asia/Shanghai"，但JWT库没显式指定时区，某些旧版本会误把时间戳当作本地时间处理 - 更隐蔽的问题：Docker容器里没设
TZ环境变量，宿主机是UTC，容器内date命令显示CST，但time()返回值仍是UTC——这种不一致会让exp比对逻辑错乱
firebase/php-jwt必须手动传入Key对象，不能只传密钥字符串
新版firebase/php-jwt（v6.10+）强制要求用Key对象传参，否则decode()会静默失败或时间校验异常。直接传$secret字符串会导致时区敏感逻辑绕过，exp判断变成纯数值比对，失去UTC语义。
- 错误写法：
JWT::decode($token, $secret, ['HS256'])→ 无法控制时区行为，且PHP 8.1+可能报Deprecated - 正确写法：
JWT::decode($token, new Key($secret, 'HS256'))→ 启用完整时间校验链 - 如果要用自定义时区（极少需要），得在
decode()前调用date_default_timezone_set('UTC')，但不推荐——JWT规范明确要求UTC，硬改时区反而增加歧义
PHP系统时间不准，比时区问题更致命
真正让JWT频繁报ExpiredException的，90%不是时区，而是服务器系统时间偏差超过5分钟。Packagist签名、GitHub OAuth Token、甚至firebase/php-jwt内部的time()比对，都依赖准确的系统时钟。
- 运行
date和访问https://time.is/对比，差超过60秒就要处理 - Linux上优先用
sudo timedatectl set-ntp true启用systemd-timesyncd，别用date -s硬调 - Docker容器要加
-e TZ=UTC并挂载/etc/timezone，否则phpinfo()里date.timezone和底层time()可能不一致 - 云服务器（如阿里云ECS）若预装
chronyd，必须停掉它再启systemd-timesyncd，两个NTP服务抢时钟会导致抖动
auth.json里的Token失效和JWT时间无关，但现象相似
很多人看到401 Unauthorized就以为是JWT过期，其实Composer报401大概率是~/.composer/auth.json里存的GitHub/GitLab Token废了——这和JWT时间校验完全无关，但错误提示容易混淆。
- 执行
composer config --global --list | grep http-basic确认当前Token是否是你刚生成的那个 - 域名必须精确匹配：填
github.com就不能写https://github.com或api.github.com - GitHub必须用classic PAT且勾选
read:packages；GitLab的password字段填的是Token字符串，不是密码 - 更新命令必须用单引号包裹Token：
composer config --global http-basic.github.com user 'ghp_abc123...'，否则$被shell展开
JWT时间问题本质是运行时逻辑，而auth.json是HTTP请求头拼接问题——两者日志里都可能出现“invalid”“expired”字眼，但根因层完全不同。
