JWT需黑名单因无状态特性无法主动作废Token，exp仅控最长有效期，登出、强制下线等场景须即时失效；生产环境必须用Redis缓存jti实现黑名单校验，且须在decode后、业务前执行，返回401/403但不泄露失效原因。
PHP 实现 API 网关鉴权时，单纯用 JWT::decode() 验签 + 检查 exp 并不能拦住已注销或被强制下线的 Token —— 黑白名单不是可选项，是生产环境的必填项。
为什么 JWT 需要黑名单（Blacklist）而不是只靠过期时间
JWT 默认无状态，服务端不存 Token 记录，所以无法主动作废。用户登出、密码修改、设备异常下线等场景下，只要 Token 还在有效期，就一直能通过验证。
-
exp字段只能限制“最长有效时间”，不能实现“即时失效” - 网关层若不做黑名单校验，攻击者拿到泄露的 Token 后，在过期前全程有效
- 阿里云/华为云等网关支持 JWT 公钥验签，但不内置黑名单逻辑 —— 这块必须由你自己的 PHP 服务兜底
PHP 中实现黑名单校验的关键点
黑名单本质是“已签发但需拒绝的 Token 的 jti（唯一标识）+ 过期时间缓存”。重点不在存储方式，而在校验时机和精度。
- 必须在
JWT::decode()成功后、业务逻辑执行前校验 —— 否则验签通过就等于放行 - 推荐用 Redis 存储，键为
jti，值可设为exp时间戳或空字符串（配合 TTL） - 不要直接存完整 Token 字符串 —— 冗余且无法去重；
jti是 JWT 标准字段，签发时必须生成并保证全局唯一 - 示例签发代码中务必包含：
'jti' => bin2hex(random_bytes(16))
如何避免黑名单校验拖慢网关性能
每次请求都查一次 Redis 确实有开销，但可通过两个策略压到毫秒级内：
- 用 Pipeline 批量查多个
jti（适用于网关聚合多服务鉴权的场景） - 对高频访问的
jti做本地内存缓存（如 APCu），设置短 TTL（比如 60 秒），命中率高时可跳过 Redis - 黑名单本身应带 TTL：Redis 中用
SETEX blacklist:{jti} 3600 {exp}，避免无限膨胀 - 注意：不要在黑名单里存“白名单式”的长期有效记录 —— 黑名单只存“已废止”，生命周期应 ≤ Token 最长有效期
白名单（Whitelist）在 JWT 场景中基本不适用
有人想用白名单控制“仅允许某些 Token 访问特定接口”，这违背 JWT 设计初衷，也极易出错：
- 白名单需要动态维护每个 Token 的权限映射，等于把 RBAC 搬到网关层，失去无状态优势
- 权限变更需同步更新所有网关节点的白名单缓存，一致性难保障
- 真正该做权限控制的地方是后端服务本身，或网关的
scope字段解析（如scope: "order:read profile:write"） - 如果真要细粒度控制，优先用 JWT 的
scope或自定义 claim（如allowed_paths），再在 PHP 中解析判断，而非维护白名单集合
最易被忽略的一点：黑名单校验失败时，必须返回明确的 401 Unauthorized 或 403 Forbidden，且不能暴露是“签名错”还是“已被拉黑”——否则攻击者可利用响应差异进行枚举探测。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
