跟人认为，它是弊大于利的一种方案
1. 关于“明文”与 JWE 的权衡
- JWT 的 Payload 只是 Base64 编码，必须用 JWE 加密，但 JWE 性能开销大。
- JWT 的初衷是“防篡改”而非“防泄露”。如果 Payload 包含敏感数据（如手机号、余额），必须加密。但加密/解密是 CPU 密集型操作。在高并发场景下，单机处理 JWT 签名校验+解密的吞吐量，远低于简单读取内存中的 Session。
- 结论：如果你必须保护 Payload 内容（除非你真的就只是放一些非常简单非常不重要的信息，否则jwe几乎是必须的），JWT 的优势（无状态）会被加密性能损耗抵消，流量一大，CPU 直接被加密算法吃满
2. 关于 LocalStorage 与跨域
- LocalStorage 不支持跨域，SSO 最终绕不开 Cookie。
- JWT 方案在浏览器端通常存放在 LocalStorage，这导致它天然无法直接在
a.com和b.com之间共享。 - 目前的 JWT SSO 方案（如 OIDC），通常是跳转到统一认证中心（CAS），该中心依然是靠 Cookie 识别用户。拿到 Token 后，再通过 URL 回传给子系统。
- 尴尬点：既然最后还是要靠认证中心的 Cookie 来维持登录态，那为什么不直接给子系统发物理 Session Cookie 呢？
3. JWT 真正的“原罪”：撤销与续期
JWT 还有一个被诟病最多的问题：不可撤销性。
- Cookie/Session：服务端想让踢掉某个会话，直接删掉 Redis 里的 Session 即可。
- JWT：除非等到过期，否则无法单方面吊销。为了实现“强踢”或“黑名单”，不得不引入 Redis 来记录失效的 Token。
- 悖论：一旦引入 Redis 做校验，JWT “无状态、不需要查库”的核心优势就彻底消失了，此时它本质上就是一个“自带数据的特殊 Session ID”。
4. 什么时候 JWT 才是“利大于弊”？
虽然它弊大于利（在传统 Web 开发中确实如此），但在以下两种场景，它是无法替代的：
- 微服务间的内部通信：网关鉴权后，将用户信息封装进 JWT 传给后端微服务。后端微服务无需再查数据库/Redis，直接解析 JWT 即可获取权限，极大降低了微服务间的耦合和网络 IO 开销。
- 移动端/非浏览器客户端：App 没有 Cookie 机制，处理 Header 里的
Authorization: Bearer <Token>比模拟 Cookie 行为要自然得多