不能只调用JWT::decode()就认为签名有效，必须显式传入密钥$key和允许算法数组$allowed_algs，并手动校验exp、nbf等时间字段，否则存在严重安全风险。
PHP中用 firebase/php-jwt 手动验证JWT签名是否有效
直接说结论：不能只调用 JWT::decode() 就算完事，它默认不校验签名，也不检查过期时间，必须显式传入 $key 和 $allowed_algs，否则等于裸奔。
常见错误现象是：伪造的 token（比如把 payload 改成 {"admin":true} 后重签一个无效签名）也能 decode 成功，只是返回数组而已——因为没校验签名，decode() 本质只是 base64url 解码 + JSON 解析。
- 必须传入真实密钥（
$key），且类型匹配：HS256 用字符串，RS256 用 PEM 公钥资源或字符串 - 必须指定
$allowed_algs数组，比如['HS256']，否则会跳过算法校验（CVE-2015-2951 类风险） - 过期（
exp）、生效时间（nbf）、签发者（iss）等都得自己检查，decode()不自动做
JWT::decode() 报错 DomainException: Algorithm not allowed
这是最常卡住人的点：不是密钥错了，而是没传 $allowed_algs 参数，或者传了但内容不匹配 header 中的 alg 字段。
比如 token header 是 {"alg":"HS256"}，但你写的是 ['RS256']，就会报这个错；更隐蔽的是漏传该参数——函数签名里它是第 3 个必填参数（v6+），旧版 v5 可能容忍空数组，但行为不可靠。
- v6.4+ 版本中，
JWT::decode($jwt, $key, $allowed_algs)第三个参数不可省略 - 别用
['none']或空数组绕过，那等于关掉签名校验 - 如果 token 来自不同服务混用多种算法（极不推荐），才考虑传
['HS256', 'RS256']，但务必确保密钥类型和算法严格对应
手动验证 exp、nbf 等时间字段的必要性
JWT::decode() 返回的是原始 payload 数组，它不会主动抛异常或过滤过期 token。你拿到 $decoded->exp 是个 Unix 时间戳，但 PHP 不会自动比对 time()。
典型翻车场景：用户登出后 token 没进黑名单，又没检查 exp，结果过期 token 还能访问敏感接口。
- 必须手动判断：
if (isset($decoded->exp) && $decoded->exp -
nbf（not before）同理，$decoded->nbf > time()就该拒绝 - 注意时区：所有时间戳都是 UTC，别用
date('U')以外的方式生成或比较
用 openssl_pkey_get_public() 加载 RS256 公钥的坑
如果你用 RSA 签名（比如 Auth0、AWS Cognito），$key 参数不能直接传 PEM 字符串，得先转成资源，否则 decode() 会静默失败或报错 Signature verification failed。
错误写法：JWT::decode($token, "-----BEGIN PUBLIC KEY-----...", ['RS256']) —— 这在 v6+ 会直接抛异常。
- 正确做法：用
$pubKey = openssl_pkey_get_public($pemString)，再传$pubKey给decode() - 记得检查返回值：
if (!$pubKey) { throw new Exception('Invalid public key'); } - PEM 字符串必须包含完整头尾（
-----BEGIN PUBLIC KEY-----），且换行符是 \n（Windows 下可能多 \r 导致加载失败）
事情说清了就结束。最常被忽略的是：decode() 不等于“验证”，它只是解码入口；真正的验证是密钥 + 算法 + 时间字段三者缺一不可的手动组合检查。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
