别再迷信 JWT 是现代开发的唯一标准了

很多开发者在写后端鉴权逻辑时，潜意识里会觉得用 Session 简直是“老古董”，而 JWT 才是云原生、分布式架构下的标准答案。这种想法其实挺危险的，因为你可能在还没搞清楚“状态（State）”到底该存在哪之前，就为了所谓的“现代感”跳进了一个巨大的坑里。

其实这两者的本质区别，不在于技术栈的新旧，而在于你打算把“真相”存在哪里。

Session 的本质是“存根”模式

你可以把 Session 理解为酒店的寄存柜。用户登录成功后，服务器在 Redis 或数据库里存一行数据（包含 UserID、角色、过期时间等），然后只给用户发一个随机的 Session ID（存在 Cookie 里）。

这个 ID 本身没有任何信息量，它只是一个“取货凭证”。

• 核心逻辑： 每次用户发起请求，服务器拿到 ID 后，必须去数据库或 Redis 里查一下：“这人是谁？他现在还有权限吗？”
• 杀手锏： 服务器拥有绝对控制权。如果发现某个账号被盗了，或者想强制某个用户下线，你只需要在后端执行一个 DELETE 操作，这个 Session 瞬间就废了，用户下一次请求直接变路人。

JWT 的本质是“签名便条”模式

JWT（JSON Web Token）完全是另一套逻辑。服务器不再记录任何东西，而是把用户信息打包成一个 JSON 对象，用私钥签个名，直接甩给客户端。

这里有个非常基础但极其容易踩坑的点：JWT 是签名，而不是加密。

你可以随手拿一个 JWT 放到终端里解码看看：

# 拿到 Token 后，直接截取中间部分进行 Base64 解码
echo "你的JWT_TOKEN_在这里" | cut -d. -f2 | base64 -d | jq

解码出来的结果可能长这样：

{
 "sub": "user_8823",
 "email": "[email protected]",
 "role": "admin",
 "exp": 1735689600
}

你看，没有任何密码，没有任何加密。任何人拿到这个 Token，都能一眼看穿里面的内容。所以，绝对不要把任何敏感信息（比如用户的手机号、内部权限标识、甚至试用期状态）写进 JWT 的 Payload 里。签名只是为了证明这封“便条”没被篡改过，并不负责保密。

到底该选哪一个？

问题的核心在于：你希望“真相”存在哪？

• 如果你追求实时控制权： 选 Session。当业务逻辑涉及到频繁的权限变更、强制踢人、或者对安全性要求极高的场景时，Session 提供的“服务器即时撤销”能力是 JWT 很难优雅实现的。
• 如果你追求极致的横向扩展： 选 JWT。因为服务器不需要查数据库，只要拿着私钥校验一下签名就能通过，这对无状态的微服务架构非常友好，能省掉大量的数据库 IO 开销。

但别忘了，JWT 带来的“无状态”是有代价的。一旦 Token 发出去，在它过期之前，你很难从物理上完全收回它的权限，除非你额外引入一套复杂的黑名单机制，而那套机制本身又让你的架构重新变回了“有状态”。