Cookie、Session、Token、JWT 是什么？万字图解带你一次搞懂！看完这篇，你连老奶奶都能教

Cookie、Session、Token 和 JWT 是用于解决 HTTP 无状态特性的身份验证和会话管理技术，它们通过不同机制实现用户状态维护，适用于不同场景。

HTTP 协议被设计为无状态协议，每个请求都是独立的，服务器不会保存客户端的状态信息。这导致以下问题：

• 用户身份无法维持：用户登录后，下一个请求服务器就“忘记”了用户是谁。
• 购物车数据丢失：用户添加商品后，换个页面购物车就空了。
• 个性化设置失效：用户的主题、语言偏好等设置无法保存。
• 用户体验极差：每次操作都要重新验证身份。

• 定义：服务器发送给浏览器的一小段数据，浏览器存储并在后续请求中自动携带。
• 工作原理：

  服务器通过 Set-Cookie 响应头将数据发送给浏览器。

  浏览器存储 Cookie，并在后续请求中通过 Cookie 请求头自动携带。

  类似银行会员卡，用户出示卡片（Cookie），服务器识别身份。

• 实战操作：

  后端（PHP）设置 Cookie：

  setcookie("user_id", "123", time() + 3600, "/"); // 有效期1小时echo "Cookie已设置";

  前端（JS）读取 Cookie：

  function getCookie(name) { const value = "; " + document.cookie; const parts = value.split("; " + name + "="); if (parts.length === 2) return parts.pop().split(";").shift();}console.log(getCookie("user_id")); // 输出: 123
• 弊端：

  安全风险：

  数据存储在客户端，用户可查看和修改，易被篡改。

  敏感信息暴露在客户端不安全。

  容易受到 XSS（跨站脚本攻击）和 CSRF（跨站请求伪造）攻击。

  存储限制：

  大小限制（通常 4KB）。

  数量限制（每个域名最多几十个）。

• 定义：将用户状态信息存储在服务器端，颁发 Session ID 给客户端，客户端通过 Cookie 携带 Session ID 访问服务端数据。
• 工作原理：

  用户登录后，服务器生成唯一 Session ID，并将用户数据存储在服务器（如内存、文件、Redis、数据库等）。

  服务器通过 Set-Cookie 响应头将 Session ID 发送给浏览器。

  浏览器存储 Session ID（通常以 Cookie 形式），并在后续请求中通过 Cookie 请求头携带。

  服务器根据 Session ID 查找用户数据，完成身份验证。

• 实战操作：

  后端（PHP）Session 用法：

  session_start(); // 启动 Session$_SESSION['user_id'] = 123; // 存储用户数据echo "Session已设置";

  前端（JS）无感知：Session ID 由浏览器自动携带，无需手动处理。

  fetch('/user/profile') .then(res => res.json()) .then(data => console.log(data));
• 优势：

  安全性高：敏感数据存储在服务器，不直接暴露给客户端。

  存储数据类型灵活：可存储任意复杂对象。

  生命周期控制：由服务器主动管理（如超时或主动注销后自动销毁）。

• 数据存储位置：

  Session：服务器。

  Cookie：用户浏览器。

• 安全性：

  Session：高（敏感数据不传输）。

  Cookie：低（可能被窃取）。

• 存储数据类型：

  Session：任意复杂对象。

  Cookie：仅文本（≤4KB）。

• 生命周期控制：

  Session：由服务器主动管理。

  Cookie：由浏览器过期时间决定。

• 定义：服务器签发的数字令牌，包含用户身份和权限信息，客户端每次请求时自主出示令牌，无需服务器存储会话状态。
• 工作原理：

  用户登录后，服务器生成 Token（通常为 JWT 格式），包含用户信息和签名。

  服务器将 Token 发送给客户端（可通过响应体或 Authorization 请求头）。

  客户端存储 Token（如 LocalStorage 或内存），并在后续请求中通过 Authorization 请求头携带。

  服务器验证 Token 的签名和过期时间，完成身份验证。

• 定义：JSON Web Token，是 Token 的一种规范，自包含的令牌格式，将用户信息（Payload）和防伪签名打包成字符串，实现无状态身份验证。
• 结构：由头部（Header）、载荷（Payload）和签名（Signature）三部分组成。

  头部：声明加密算法，如 HS256。

  { "typ": "JWT", "alg": "HS256"}

  载荷：包含用户信息和元数据，如 exp（过期时间）、sub（用户 ID）等。

  { "iss": "
  http://localhost"
  , "iat": 1587000625, "exp": 1618536625, "nbf": 1587000625, "jti": "iCxsfo97UVUijjjP", "sub": 1, "prv": "13e8d028b391f3b7b63f21933dbad458ff21072e"}

  签名：由服务器生成，保证 Token 不被篡改。

  HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

• 验证流程：

  获取客户端提交的 Token。

  检测 Token 中的签名 Signature 是否正确。

  判断 Payload 数据中的 exp 是否已过期。

  根据 Payload 数据中的 sub，查询数据库验证用户是否存在。

  上述检测不正确，则抛出相应异常。

• 存储位置：

  Cookie：浏览器。

  Session：服务器（Session 存储）。

  Token：客户端（LocalStorage/Cookie）。

• 存储内容：

  Cookie：Key-Value 数据。

  Session：用户会话数据对象。

  Token：自包含的签名令牌（包含声明）。

• 状态管理：

  Cookie：客户端存储状态片段。

  Session：服务器端管理状态。

  Token：无状态。

• 传输方式：

  Cookie：自动通过 Cookie 请求头。

  Session：通过 Cookie/URL 传递 Session ID。

  Token：手动添加（常放 Authorization Header 中）。

• 安全性：

  Cookie：较低（易被窃取/篡改）。

  Session：较高（敏感数据在服务器）。

  Token：较高（签名防篡改）。

• 扩展性（分布式）：

  Cookie：好（无状态）。

  Session：差（需 Session 共享方案）。

  Token：极好（天然无状态）。

• 跨域支持：

  Cookie：受限（同源策略/CORS 配置）。

  Session：受限（依赖 Session ID 传输）。

  Token：好（配合 CORS）。

• 移动端/Web 端：

  Cookie：一般浏览器环境为主。

  Session：一般浏览器环境为主。

  Token：浏览器、APP 端都可以使用。

• 典型应用场景：

  Cookie：跟踪、简单配置、Session ID 载体。

  Session：传统服务器渲染 Web 应用。

  Token：现代 SPA、移动 App、API 服务、微服务。