JWT 还是会话：如何选择认证模型

"该用 JWT 还是传统会话？"几乎是每个团队在做认证时都会遇到的问题。网上常把 JWT 说成现代、先进，把会话说成过时，但这种二元对立其实误导人。两者本质上是两种不同的取舍，各自在某些场景里更合适。要选对，关键不是追新，而是理解它们在状态管理、撤销能力和扩展性上的真实差异。

两种模型的根本差别

传统会话是有状态的：服务器在自己这边保存会话数据，客户端只持有一个不透明的会话标识，每次请求都靠它去服务器查出对应的用户。JWT 则是无状态的：必要信息直接装在令牌里，并用签名保证可信，服务器无需保存任何东西，验证签名即可信任。

"状态存在哪里"——这一个区别，几乎衍生出了它们之后所有的优劣对比。理解了这一点，其余的取舍就都顺理成章了。

因为服务器掌握着会话，传统会话可以随时作废一个登录：用户登出、修改密码、或被管理员强制下线时，服务器直接删掉对应的会话即可，效果立竿见影。这种即时撤销能力，对安全要求高的系统非常重要。

JWT 在这一点上天然吃亏。令牌一旦签发，在过期前很难单方面作废，因为服务器并不保存它。要实现撤销，往往得引入撤销名单或缩短有效期——而这些手段又把一部分状态加了回来，削弱了无状态的初衷。

当系统横向扩展到多台服务器，甚至多个独立服务时，有状态会话就需要一个共享的会话存储，让所有节点都能查到同一份数据。这增加了基础设施的复杂度和一个潜在的瓶颈。

JWT 在这里发挥优势：任何持有密钥的服务都能独立验证令牌，不必访问共享存储。对于分布式、多服务、或跨域的架构，这种"自包含、可独立验证"的特性能显著简化设计。这也是 JWT 在微服务场景里流行的根本原因。

会话标识通常很短，因为真正的数据都在服务器那边。JWT 则把声明都装进令牌，随每个请求一起发送，因此体积更大。如果往载荷里塞太多东西，每次请求都要多传一份不小的数据，累积起来会影响性能。

所以使用 JWT 时要克制载荷，只放必要的声明。如果你发现令牌越来越臃肿，那可能是个信号：有些数据本就该留在服务器，而不是装进每一个令牌里到处跑。

传统会话的逻辑相对成熟，框架通常封装得很好，开发者不太容易在安全上踩坑。JWT 则把更多责任压到了实现层：算法校验、密钥管理、声明验证、撤销策略，每一步都可能出错，而错了往往就是安全漏洞。

这意味着 JWT 的"无状态便利"不是免费的，它换来的是更高的实现谨慎度要求。如果团队没有把握把这些细节都做对，选用一套成熟的会话方案反而更稳妥。

现实中很多系统并不二选一，而是把两者结合。一种常见模式是用短有效期的 JWT 做无状态的访问令牌，享受扩展性；同时用一个有状态的刷新令牌来换取新令牌，从而保留撤销能力。这样既拿到了 JWT 的扩展优势，又补上了它撤销困难的短板。

这种混合恰恰说明：JWT 和会话不是对立的阵营，而是可以组合的工具。看清各自的取舍，再按系统的真实需求去搭配，远比纠结"哪个更先进"更有意义。

最终的选择应当回到你的系统特征：如果即时撤销和简单可靠最重要，传统会话往往是更稳的选择；如果无状态扩展和跨服务验证是刚需，JWT 更合适；如果两者都要，混合方案值得考虑。

别被"现代 vs 过时"的叙事带偏。认证模型的好坏，从来不取决于它新不新，而取决于它的取舍是否匹配你要解决的问题。