引言：从"去中心化"的理想说起
那年的那个深夜，当我次在微服务架构中写下 Authorization: Bearer <jwt> 时，我以为自己握住的是服务间通信的圣杯——无状态、自包含、横向扩展如丝般顺滑。那时的我们，正急于逃离 Session 共享的（Redis 单点、Sticky Session、序列化噩梦），JWT 的出现像极了普罗米修斯的火种。
但十年后，当我凝视着那个膨胀到 8KB 的 Token 在 Header 中横冲直撞，或是在调试一个因权限延迟 200ms 而被用户投诉的接口时，我才明白：架构没有银弹，只有权衡的艺术。
让我们穿越技术史的迷雾，看看胖瘦之争如何在不同的时代语境下反复横跳。
章：史前时代（2010 年前）—— Session 的暴政与 JWT 的诞生
场景：单体巨石应用
在那个 SSH/SSM 框架横行的年代，HttpSession + Cookie 是身份认证的唯一真理。用户登录后，Tomcat 在内存中创建一个 Session 对象，浏览器种下 JSESSIONID。
架构痛点：
- 水平扩展之殇：Nginx 反向代理后，Session 必须共享（Tomcat 集群广播、或外挂 Redis）
- 跨域之痛：CORS 政策严格，Cookie 的 SameSite 属性让人抓狂
- 移动端适配：原生 App 处理 Cookie 总显得格格不入
架构是时间的艺术
回到最初的问题：胖 JWT 还是瘦 JWT？
十年前的我选择了胖，因为想摆脱数据库的枷锁；五年前的我选择了瘦，因为无法忍受数据不一致的焦虑；今天的我选择让基础设施来决定——在边缘让 Token 胖一点，在中心让它瘦一点，在数据库前让缓存聪明一点。
架构没有正确答案，只有对约束条件的深刻理解。 当你下次设计鉴权方案时，不要问"社区推荐什么"，要问：
- 我的网络拓扑允许我查库吗？
- 我的业务能容忍几分钟的权限延迟吗？
- 我的 Token 经过了多少个不可信的中间节点？
- 当用户点击"注销"时，我能否承受他还能操作 2 分钟的代价？
想清楚这些，胖瘦自然分明。
记住：JWT 只是一个容器，真正的架构智慧在于——你知道什么时候该信任携带的信息，什么时候该保持怀疑并亲自验证。这种怀疑精神，才是架构师最宝贵的品质。