大家好，我是石头~

       今天咱们来聊聊程序员圈子里一个老生常谈的话题——JWT与Session。

       这俩家伙在身份验证的世界里可是大名鼎鼎。每当新项目启动，或者旧系统升级，关于“JWT好还是Session好”的争论就如约而至。

       那它们究竟有何神通，又各自适合怎样的场景呢？

       别急，接下来咱就把它们掰扯清楚，帮你找到最适合自家项目的“真命天子”！

1、JWT：轻装上阵的无状态小能手

●JWT是个啥？

       JWT，全称JSON Web Tokens，就像一张特殊的电子身份证，里面包含了用户的认证信息。这张身份证被精心设计成三段式：头（说清楚这是个JWT）、身子（装着用户数据）、尾（盖个戳确保没人乱改）。（了解JWT详细信息可进入《JWT：你真的了解它吗？》）

       然后，它会被编码成一串字符串，随HTTP请求在客户端和服务端之间飞来飞去。

●JWT的独门秘籍

1. 无状态神功：服务器不记仇（不对，是不记用户会话信息），全靠客户端带着JWT自己证明身份。这样既减轻了服务器压力，又能轻松应对分布式部署，简直是微服务架构的福音。

2. 跨界高手：因为JWT藏在HTTP头里，天生支持跨域访问，API接口调用那叫一个爽快。

3. 安全护盾：签名机制确保了JWT内容不会被偷偷篡改，让你用得安心。

●JWT也有软肋

1. 过期管理不易：JWT的有效期得拿捏好，太短吧，用户可能刚喝口水回来就得重新登录；太长吧，万一令牌丢了，风险就大了。

2. 想撤回？没那么简单：发出去的JWT就像泼出去的水，需要增加缓存机制才能撤回，否则需要等它自然过期，或者记它一笔在黑名单，没有其他办法主动撤销。

3. 个头儿有点大：要是JWT里塞太多东西，长度就会变长，可能影响网络传输速度。

2、Session：稳扎稳打的传统守护者

●Session是何方神圣？

       Session嘛，就是服务器给每位登录用户发的一张VIP卡（Session ID）。用户每次来访，出示这张卡，服务器就能认出他，给他相应的服务。这张VIP卡一般藏在Cookie里，由浏览器贴心保管。

       Session的认证流程如下图：

●Session的看家本领

1. 一手掌握用户会话：服务器亲自管着所有用户的Session信息，想创建、更新、销毁或者设置有效期，都是一句话的事儿，权限控制灵活得很。

2. 令牌召回无压力：只要从服务器的Session池子里撤掉某张VIP卡，对应的用户会话立马失效，安全性妥妥的。

3. 肚量大，能装事儿：服务器端存储会话信息，不像JWT有长度限制，哪怕业务再复杂也不怕。

●Session的阿喀琉斯之踵

1. 服务器压力山大：用户越多，服务器要记的VIP卡越多，内存消耗那是哗哗的。

2. 跨域是个麻烦事：Session依赖Cookie，跨域时得多费点心思，比如设置 CORS 或者用 Token 传 Session ID。

3. 分布式架构，头疼：多台服务器怎么共享Session信息？要么“粘性会话”让用户老找同一位服务器，要么搞个Session复制，总之复杂度上去了。

3、应用场景大比拼

1. 微服务、API Gateway等分布式架构：这种环境下，JWT无状态、易扩展的特性简直是量身定制，绝对是主力选手。

2. 单体应用、内部系统等非分布式场景：如果没啥跨域、分布式的问题，对用户会话管理要求又高，Session就是你的贴心小棉袄。

3. 移动应用、SPA等前端技术栈：现代前端应用跟JWT更搭哦，跨域友好、容易集成，还能帮网络请求减负。

4、结语：萝卜青菜，各有所爱

       JWT和Session，一个是轻装上阵的无状态小能手，一个是稳扎稳打的传统守护者。选谁，关键看你的项目需求、技术架构和团队偏好。没有绝对的优劣，只有适不适合。所以，别再问“JWT和Session哪个好”了，先理清自家情况，答案自然浮出水面。

**MORE | 更多精彩文章**

• H5推送，为什么都用WebSocket？
• 别再这么写POST请求了~
• 揭秘布谷鸟过滤器：一场数据过滤中的“鸠占鹊巢”大戏！
• JWT：你真的了解它吗？