Cookie、Session、Token、JWT 原理 + 流程 + 区别 + 实战

HTTP 无状态 :底层原理、完整执行流程、数据结构、安全机制、优缺点、适用场景HTTP 是无状态协议服务器不记忆任何用户信息请求之间毫无关联。→ 无法实现登录、购物车、个人中心、权限校验。所以必须给 HTTP 强行 “加状态”这就是 Cookie、Session、Token、JWT 诞生的根本原因后续状态指的是什么意思:在Web 身份认证 / 服务端会话这个语境下「状态」特指服务端需要主动存储、维护的「用户会话信息」比如用户 ID、登录状态、权限、会话有效期等用来识别和关联同一个用户的多次请求。关键区分有状态Stateful服务端必须在本地存储用户的会话数据每次请求都要从存储中查询、校验这个状态才能识别用户。无状态Stateless服务端不需要存储任何用户会话数据所有身份信息都由客户端在请求中携带服务端只需要验证信息的合法性就能识别用户不依赖本地存储。一、Cookie浏览器的 “存储小盒子”原理 细节1. 官方定义Cookie 是服务器通过响应头种植、浏览器自动存储、自动携带的键值对文本数据。它不是认证方案它是存储载体。2. 底层原理HTTP 头工作流程第 1 步服务器下发 Cookie登录成功后服务器在响应头里加Set-Cookie: userId123; Expiresxxx; HttpOnly; Secure; SameSite浏览器自动解析并保存到本地。第 2 步浏览器自动携带 Cookie下次请求同一域名时请求头自动带上Cookie: userId123全程无需代码干预。3. Cookie 核心属性决定安全与行为属性作用Expires/Max-Age过期时间HttpOnly禁止 JS 读取防 XSS 窃取Secure仅 HTTPS 传输SameSite防 CSRF 跨站攻击4. 本质局限大小限制4KB纯文本可篡改不能存敏感信息密码、身份证浏览器专属APP 不支持二、Session服务器的 “会话账本”原理 流程1. 一句话原理Session 服务器内存 / 缓存中的用户数据Cookie 存 SessionID钥匙Session 是有状态认证。2. 完整执行流程最经典的 Web 登录① 登录请求用户输入账号密码 → 后端验证成功② 服务器创建 Session生成唯一 SessionIDsess_abc123 服务器存储 sess_abc123 → { userId: 1, username: 张三, login: true }③ 服务器把 SessionID 写入 CookieSet-Cookie: JSESSIONIDsess_abc123; HttpOnly④ 后续请求浏览器自动携带 CookieCookie: JSESSIONIDsess_abc123⑤ 服务器验证服务器根据sess_abc123查存储 → 拿到用户信息 → 认证通过。3. Session 底层原理Session 存储内存、Redis、数据库SessionID随机字符串无法猜测依赖 Cookie没有 CookieSession 几乎无法工作4. Session 致命缺点服务器有状态→ 无法随便扩容分布式 / 集群必须共享 SessionRedis 方案跨域极难Cookie 不支持跨域APP 不友好APP 没有浏览器 Cookie 机制三、Token通用 “加密身份凭证”1. 核心思想服务器不存储任何用户状态 → 彻底无状态Token 服务器签发的身份字符串2. 与 Session 最大区别Session服务器存数据 → 查库验证Token服务器不存数据 → 解密 / 验签验证3. Token 工作流程① 登录成功服务器生成 Tokentoken encrypt(用户信息 过期时间 签名)② 返回给前端前端自己存储localStoragecookievuex/react state③ 后续请求手动携带前端在请求头里手动加Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...④ 服务器验证解密 / 验签 → 合法 → 通过4. Token 优点无状态服务器零存储天然支持分布式、微服务跨域友好支持 APP、小程序、Web 全端四、JWTToken 的标准实现最详细原理1. 官方全称JSON Web Token它是一套标准化的 Token 格式不是新技术。2. JWT 核心特点自包含 防篡改 跨语言3. JWT 数据结构三段式。分割Header.Payload.Signature① Header头部声明加密算法默认 HS256{ alg: HS256, typ: JWT }② Payload负载存放用户数据不加密仅编码{ sub: 1, name: 张三, exp: 1735689600 }Payload 可以被任何人解码绝对不能存密码③ Signature签名【核心安全】Signature HMACSHA256( Base64(Header) . Base64(Payload), 密钥 (SecretKey) )作用防止篡改只要内容被改签名立刻失效。4. JWT 验证原理超级重要前端传 JWT后端拆分出 Header.Payload.Signature用同样密钥重新计算签名对比新签名 vs 旧签名一致 → 未篡改可信不一致 → 伪造拒绝5. JWT 优点无存储、无状态跨语言、跨平台微服务、前后端分离首选不依赖 Cookie6. JWT 缺点必须知道无法主动作废未过期的 JWT 永远有效想拉黑只能加黑名单RedisPayload 可解码敏感信息禁止放入体积比 SessionID 大五、终极对比4 者本质关系彻底懂一句话总结Cookie浏览器存储工具Session服务端存储状态依赖 CookieToken无状态身份凭证JWTToken 的标准格式最清晰的层级关系plaintextHTTP 无状态 ↓ Cookie存储 ↓ Session基于 Cookie 的服务端状态 ↓ Token无状态、跨平台 ↓ JWT标准 Token核心区别表维度CookieSessionTokenJWT存储位置客户端服务端客户端客户端服务端存储无有无无传输方式自动自动手动手动跨域不支持不支持支持支持分布式不支持需共享天然支持天然支持安全性中高高高适用端WebWeb全端全端六、实战选择指南工作中怎么选1. 传统 Web 项目不分离Session Cookie最简单、最安全。2. 前后端分离 / 微服务 / 小程序 / APPJWT行业标准方案。3. 超高安全需求金融、支付JWT 黑名单 短过期 HTTPSQ1Session 为什么不适合分布式因为状态存在服务器本地其他服务器查不到。Q2JWT 为什么安全因为签名无法伪造内容一改就失效。Q3Cookie 被禁用了怎么办Session 会失效但 JWT 不受影响。Q4JWT 能存密码吗绝对不能因为 Payload 可解码。Q5JWT 泄露了怎么办没办法只能等过期或拉黑。