jwt签名验证失败主因是signature未转标准base64：需strtr()+rtrim()预处理；私钥须pem格式且无密码；算法须严格匹配rs256/hs256；exp校验需统一utc时区并允许30秒误差。
JWT签名验证失败：openssl_verify() 返回 0 怎么办
PHP 原生 JWT 验证失败，大概率不是算法写错，而是密钥格式或签名编码没对齐。JWT 的 signature 是 Base64Url 编码（非标准 Base64），而 openssl_verify() 要求原始二进制签名；直接传入 JWT 中的 signature 段必然失败。
- 拆出 JWT 的三段后，用
strtr()和rtrim()把 signature 段转成标准 Base64 再base64_decode()，才能喂给openssl_verify() - 私钥必须是 PEM 格式（以
-----BEGIN PRIVATE KEY-----开头），且不能被密码保护；否则openssl_pkey_get_private()返回false - 算法必须严格匹配：HS256 用
hash_hmac()，RS256 必须用openssl_verify()+ PEM 公钥，混用会静默失败
用 firebase/php-jwt 解析时抛 DomainException: Wrong number of segments
这个错误只说明输入字符串根本不是合法 JWT 格式——三段（header.payload.signature）缺一不可，且必须用英文点号 . 分隔。常见于前端没传全、中间件截断、或者误把 token 存在 query 参数里被 URL 编码破坏。
- 检查原始字符串是否含空格、换行或中文标点；
trim()和urldecode()是前置必需操作 - 如果从 Authorization Header 取值，注意格式是
Bearer <token></token>，得先explode(' ', $header)[1]提取，别直接整个丢进去 - 该库不自动处理 Base64Url → Base64 转换，但最新版（v6+）已内置修复；若用老版本，需手动预处理 signature 段
为什么 exp 字段校验总过期？时间戳对不上
JWT 的 exp 是 Unix 时间戳（秒级整数），而 PHP 的 time() 是秒级，看似没问题，但实际常因服务器时区、NTP 同步偏差、或客户端本地时间伪造导致校验失败。
mallcloud商城
下载
mallcloud商城基于SpringBoot2.x、SpringCloud和SpringCloudAlibaba并采用前后端分离vue的企业级微服务敏捷开发系统架构。并引入组件化的思想实现高内聚低耦合，项目代码简洁注释丰富上手容易，适合学习和企业中使用。真正实现了基于RBAC、jwt和oauth2的无状态统一权限认证的解决方案，面向互联网设计同时适合B端和C端用户，支持CI/CD多环境部署，并提
- 服务端务必用
date_default_timezone_set('UTC')统一时区，避免strtotime()解析出错 - 不要依赖客户端传来的
iat或nbf做逻辑判断；它们可被篡改，仅exp由服务端签名保障可信 - 生产环境建议加个宽松窗口，比如允许最多 30 秒误差：
$payload['exp'] > time() - 30，而不是严格大于
JWT 存在 Cookie 还是 localStorage？PHP 后端要怎么设
存哪不归 PHP 管，但 PHP 输出响应时若要设 Cookie，必须明确 HttpOnly 和 Secure 标志，否则 token 泄露风险极高。
立即学习“PHP免费学习笔记（深入）”；
- 用
setcookie()时，第 7 个参数$options数组里必须含'httponly' => true, 'secure' => true, 'samesite' => 'Strict' - 别用
$_SESSION存 JWT——它本质是服务端状态，违背 JWT 无状态设计初衷；JWT 就该由前端携带、后端纯验证 - 如果走 Cookie 方案，前端 fetch 要加
credentials: 'include'，否则浏览器不发 Cookie
真正麻烦的从来不是生成 token，而是密钥轮换、黑名单撤销、以及签名密钥在多台服务器间的一致性同步——这些没法靠一个 JWT::encode() 解决。
