JWT（JSON Web AI 词典：Token">Token）是一种把“你是谁、能干什么、什么时候失效”打包成一段自带签名的字符串，交给客户端自己保管的凭证格式。
它长这样：xxxxx.yyyyy.zzzzz，三个点把内容分成三段。第一段是头部（header），说明用了哪种签名算法；第二段是载荷（payload），装着用户 ID、角色、过期时间这些声明（claim）；第三段是签名（signature），用服务端的密钥对前两段算出来的。
打个比方：你去音乐节，入口处核验身份证后给你戴上一个手环，手环上印着“VIP、有效期至今晚 12 点”。之后你进出各个分区，保安只低头看一眼手环的颜色和字样就放行——他不需要打电话回总台查名单。JWT 就是这个手环：服务端签发之后就把这事忘了，不再在内存或数据库里保存任何记录，这就是所谓的“无状态”（stateless）。
验证过程也像验手环。服务端拿到 token，用同一把密钥（HMAC 算法）或者配对的公钥（RSA/ECDSA 算法）把前两段重新算一遍签名，和第三段比对。对得上，说明内容没被改过、确实是自家签发的；对不上，直接 401。整个过程不查库、不联网，一台机器能验，一百台机器也能验，横向扩容非常省事。
这里有个必须说清的点：payload 只是 Base64URL 编码，不是加密。任何人拿到 token 都能解出里面的内容，所以别往里塞手机号、身份证号之类的敏感信息。签名保证的是“没被篡改”，不是“看不见”。
那为什么说它“发出去就撤不回”？因为吊销依赖的是服务端记着“谁还有效”，而无状态的设计恰恰把这个记录删掉了。token 一旦签发，在过期之前，任何持有密钥的服务端都会认它——除非你额外维护一份黑名单或版本号，那又变回有状态了。所以业界的通行做法是：把 access token 的有效期设得很短，几分钟到一小时量级；另配一个长效的 refresh token（刷新令牌），存在服务端可控的地方，用户无感续期。真要“踢人下线”，就作废对应的 refresh token，让攻击者手上那个短命 access token 自然过期。
具体时长没有标准答案，取决于业务风险：银行类操作可以短到几分钟，内部工具长一点也无妨。原则是“短到攻击者来不及用，长到用户不觉得烦”，以各家官方文档和自身风控要求为准。
| JWT | 传统 Session Cookie | |
|---|---|---|
| 状态存在哪 | 客户端（token 自身） | 服务端（session 存储） |
| 验证要不要查库 | 不用，验签即可 | 通常要 |
| 能否立刻失效 | 难，需额外黑名单 | 容易，删 session 即可 |
| 多机扩容 | 简单，共享密钥/公钥 | 需共享存储 |
对做 AI 应用的人来说，这套机制天天在脚下：你调第三方模型 API 拿到的 access token、你给自家 Agent 做的多用户鉴权、你接的 OAuth 登录，背后多半是同一套逻辑。记住三条就够用——payload 不加密，别放秘密；签名只管真伪，不管撤销；过期时间要短，续期靠 refresh token。