在 Web 开发的世界里，有一个基本事实我们必须首先了解：HTTP 协议是无状态的（Stateless）。
这意味着，服务器不会“记住”任何关于用户的信息。你第一次访问网站和你一秒钟后再次刷新页面，对于服务器来说，都是两次全新的、独立的请求。它不知道这两个请求都来自同一个人。
但这显然无法满足现代应用的需求。我们需要网站能记住我们的登录状态、购物车里的商品、个性化设置等等。为了解决这个问题，聪明的工程师们发明了多种机制来“维持状态”，其中最核心、最常见的三种就是 Cookie、Session 和 Token。
它们分别是什么？
为了更好地理解，我们可以用一个逛游乐园的比喻。
1. Cookie：游乐园的“临时通行证”
Cookie 就是一张由服务器（游乐园）发给你，并由你自己（浏览器）保管的通行证。它是一小段存储在用户浏览器上的文本数据。当你访问网站时，浏览器会自动带上它，服务器通过读取它来识别一些基本信息。
2. Session：游乐园的“储物柜钥匙”
Session 是一种将用户数据存储在服务器端的机制。服务器不再把所有信息都写在通行证上，而是为你分配一个专属的“储物柜”（服务器上的一块内存），存放你的个人信息。然后，它只给你一把带有唯一编号的“钥匙”（Session ID），这把钥匙通常通过 Cookie 发送给你。你只需要带着钥匙，服务器就能找到你的储物柜。
3. Token：游乐园的“加密腕带”
Token（通常指 JWT）是一个包含了用户信息并经过加密签名的“凭证”。它就像一个高科技腕带，本身就包含了你的所有信息（如“VIP权限”、“有效期”），并且有一个无法伪造的特殊签名。服务器不需要储物柜，只需用特殊的扫描仪验证腕带的真伪，就能确认你的身份和权限。
共同点：为了解决同一个问题
尽管三者在实现上有所不同，但它们的出发点是完全一致的：
核心目标相同：都是为了解决 HTTP 协议的无状态性，让服务器能够“记住”用户，从而跟踪和维持用户的会话状态（比如登录状态）。
都是身份验证的手段：它们都承载了用户的身份凭证，让用户在一次次请求中无需反复输入用户名和密码。
都涉及客户端与服务器的交互：都需要客户端在后续的请求中，将某种形式的凭证发送给服务器。
不同点：实现机制与应用场景的差异
这三者的核心区别在于数据的存储方式和服务器的状态，这直接决定了它们的安全性和适用场景。
让我们来详细解读这些不同点：
存储位置 & 安全性
Cookie：数据直接存在客户端浏览器上，且是明文或简单编码，容易被窃取和篡改，非常不安全，绝不能存储敏感信息。
Session：核心数据存在服务器上，只将一个无意义的 Session ID 通过 Cookie 发给客户端。这大大提升了安全性，因为黑客即使拿到了钥匙（ID），也无法直接获取储物柜里的东西。
Token：数据也存在客户端。但它的安全性来自于“签名”（Signature）。Token 包含了用户信息，但这些信息被服务器的密钥签了名。当服务器收到 Token，会先验证签名是否有效。如果信息被篡改，签名就会失效，请求会被拒绝。
服务器的状态与压力
Cookie & Token：对于服务器来说是无状态的。服务器不需要为用户保留任何信息。对于 Token，服务器甚至不需要查询数据库，只需验证签名即可，这极大地减轻了服务器的压力。
Session：是有状态的。每个在线用户，服务器都需要为其维护一份会话数据（一个储物柜）。当用户量巨大时，这将消耗大量的服务器内存资源，对服务器造成压力。
扩展性与跨域支持
Session：在分布式或微服务架构下会遇到麻烦。如果用户第一次请求被服务器A处理，第二次被负载均衡到服务器B，服务器B上并没有这个用户的“储物柜”，验证就会失败。这需要做复杂的会话共享配置。
Token：天生适合分布式架构。因为服务器是无状态的，任何一台服务器只要拥有相同的密钥，就能独立验证 Token 的有效性，扩展性极佳。同时，Token 通过 HTTP Authorization 头发送，不存在 Cookie 的跨域（CORS）限制问题。
结论
Cookie 是“明文通行证”，简单但不安全，通常只作为承载其他凭证的载体。
Session 是“储物柜钥匙”，将安全风险留给了服务器，但在用户量大或分布式场景下会成为瓶颈。
Token 是“加密腕带”，安全、高效、可扩展，是现代应用架构（尤其是API、单页应用、微服务）的宠儿