首先，用一个简单的比喻来建立直观理解：
Cookie = 会员卡（由店家发放，你每次来都出示，上面可能只有卡号）。
Session = 店家后台的会员档案（根据你的卡号，在店里的电脑中查到的详细消费记录、偏好等信息）。
Token (JWT为代表) = 盖了章的加密令牌/门票（你持有这个令牌，店家只要检验令牌本身的真伪和内容即可，无需去查后台档案）。
1. Cookie 与 Session 的“经典组合”
在传统的Web开发中，Cookie和Session是协同工作的：
Cookie是载体：它只负责安全地存储和传递一个密钥——Session ID（一个随机字符串）。
Session是内容：服务器用这个Session ID作为key，在服务器端的存储（如Redis）中查找对应的value，即用户的完整会话数据（如 {user_id: 123, username: 'Alice'}）。
核心问题：这种模式是有状态的，服务器必须保存和维护所有会话数据，对于大型分布式应用是负担。
2. Token (JWT是典型代表) 的革新
Token（特别是JWT）的出现是为了解决Session的扩展性问题，实现无状态认证。
自包含：Token（如JWT的Payload部分）直接包含了用户身份信息（如{user_id: 123, username: 'Alice'}）和其他声明。
可验证：Token经过服务器密钥签名，接收方可以验证其是否被篡改，而无需查询数据库或会话存储。
存储灵活：Token由客户端保存，可以放在LocalStorage、SessionStorage或Cookie中（但需注意不同存储方式面临的安全风险）。
3. 关键总结与选择
Cookie vs Session： 不是一个维度的比较。Cookie是客户端存储和传递机制，Session是服务器端数据存储方案。它们通常搭配使用。
Session vs Token： 这才是两种不同的身份认证/会话管理架构的核心对比。
Session（有状态）： 更“传统”，服务器控制会话生命周期，易于管理（可强制下线），但扩展性复杂。
Token（无状态）： 更“现代”，适合RESTful API、移动端、跨域（CORS）和微服务架构，扩展性强，但令牌一旦签发，在过期前难以废止（需额外机制如黑名单）。
现代实践中的常见模式：
传统Web应用（SSR）： 仍广泛使用 Cookie + Session（Session存于Redis）。
前后端分离（SPA + API）： 普遍使用 Token（JWT），通过HTTP头传递。
兼顾安全与便利： 使用短期的Access Token（JWT） + 长期的Refresh Token，Refresh Token以安全的方式（如HttpOnly Cookie）存储。