我真的厌倦了假装 JWT（JSON Web Token）很好用。事实上面对现实吧：它是一个盲目崇拜的产物（Cargo Cult）。它解决了一个你的应用几乎绝对不存在的问题，却带来了四五个你的应用绝对会遇到的麻烦。整整一代后端开发者被 2014 年左右的某些博客文章所误导，把“无状态（Stateless）”当成了一种绝对的美德，而不是一种权衡（Trade-off）。
在实际的项目审计中，我发现每一个基于 JWT 的系统都存在相同的问题：破碎的凭证撤销机制、毫无意义的双 Token 刷新逻辑，以及前端直接解码并信任 Payload 数据的安全漏洞。如果你正在构建 Web 应用、移动 App 或第一方 API，JWT 绝对是错误的默认选择，请立即停止使用它。在 Postgres 中存一行 Bearer Token 记录，不仅更快、更简单，而且严格来说更加安全。
让我们剖析一下 JWT 的本质。JWT 由三部分组成：头部（Header）、JSON 载荷（Payload）和签名（Signature）。签名通常是 HMAC 或 RSA/ECDSA 算法生成的。它的卖点在于：服务器签名，客户端携带，随后的每次请求只需进行签名验证，无需查询数据库，从而实现“无状态身份验证”。这就是它的整个价值主张。然而，只要问一个问题，这个美妙的谎言就会不攻自破。
那就是：在过期时间（exp）截止前，你如何让一个用户强制下线？
答案是：你做不到。在 Token 到期之前，它永远有效。唯一的撤销方法是在服务端维护一个黑名单（Revocation List），并在每次请求时查询该列表。这不仅需要数据库查询，而且直接击碎了 JWT “免去数据库轮询”的初衷。恭喜你，你以极其拙劣的方式重新发明了 Session（会话管理）。
最终，你只能在两个糟糕的方案中做二选一：
第一，不进行即时撤销。被盗取的 Token 在过期前持续有效。为了不让用户频繁登录，生产环境中充斥着有效期长达 1 年、5 年甚至 10 年的 Token。这意味着“退出所有设备”按钮名存实亡，重置密码也无法踢出攻击者。
第二，维护撤销列表。此时你既要承担 JWT 签名验证的 CPU 开销，又要承担数据库/Redis 的查询开销，得不偿失。在这两者之间，从来没有第三种选择。
【AgentUpdate 深度解析】 随着 AI Agent 走向主动执行与多 Agent 协同，身份验证（Auth）的底座正在发生根本性改变。在 Agent 生态中，Agent 拥有极高的 API 调用自主权，极易遭受提示词注入或行为失控。在这种场景下，JWT 的“无状态、难即时撤销”特性的隐患被无限放大。如果一个 Agent 出现异常，安全系统必须具备“微秒级”的即时阻断能力。传统的无状态 JWT 无法做到这一点，而基于 MCP（Model Context Protocol）或有状态 Bearer Token 的动态权限校验，能够实现对 Agent 权限的实时收紧与吊销。未来，面向 Agent 时代的 Auth 方案必将抛弃 JWT 这种粗放的无状态签名，转向具备极细粒度、实时可控的“有状态能力令牌（Capability-based Tokens）”，这才是支撑高频、动态 Agent 协作的安全基石。
