深入理解 Cookie、Session、JWT 的原理、实现和区别

前言

在 Web 应用中，身份认证是绕不开的核心话题。「登录状态如何保持？」「用户身份如何验证？」—— 围绕这些问题，最主流的三种方案是 Cookie、Session 和 JWT。本文将系统梳理三者的原理、实现方式及适用场景。

1.1 原理

Cookie 是由服务器通过 HTTP 响应头 Set-Cookie 发送给浏览器的小型文本文件，浏览器会自动将其存储并在后续请求中通过 Cookie 请求头带回。

1.2 工作流程

1.3 优缺点

优点	缺点
不占用服务器资源（存储在客户端）	仅支持字符串格式
实现简单	存储量有限（一般 4KB）
	数据容易被获取和篡改
	容易丢失（用户清除、过期）

1.4 适用场景

Cookie 适合存储简单、非敏感的数据，以及需要浏览器自动发送的场景：

电商购物车：用户未登录时，将商品 ID 和数量存入 Cookie，结账时合并登录后的购物车数据
记住登录状态：「下次自动登录」功能，延长会话有效期
用户偏好设置：主题、语言、字体大小等个性化配置
页面临时状态：表单草稿、分页位置等临时数据

典型业务：小型展示型网站、无用户体系的简单应用、需要 SEO 的内容站点

二、Session

2.1 原理

Session 将用户数据存储在服务器端，仅在客户端保留一个 Session ID。服务器通过这个 ID 识别用户身份。

2.2 工作流程

2.3 优缺点

优点	缺点
支持任意格式（对象、数组等）	占用服务器内存
理论上存储量无限	服务器重启会丢失（需配合持久化）
数据难以被获取（仅暴露 ID）
数据难以篡改
不易丢失（存储在服务端）

2.4 适用场景

Session 适合需要高安全性、数据量适中、服务器资源充足的场景：

银行/金融系统：账户余额、交易密码等敏感数据必须存于服务端，任何客户端存储都存在泄露风险
后台管理系统：管理员操作日志、权限变更、审计追踪等需要服务端强控制的数据
电商核心流程：结算页面的订单数据、库存锁定状态，防止用户篡改价格或库存数量
企业内部系统：HR 系统、财务系统等仅内网访问、对安全性要求高的应用

典型业务：传统 Web 应用（PHP/JSP/ASP.NET）、企业内部系统、政务平台、在线交易系统

三、JWT（JSON Web Token）

3.1 原理

JWT 是一种自包含的令牌格式，将用户信息编码后与签名一起传输，服务器通过验证签名来确认令牌有效性。

3.2 组成结构

JWT 由三部分组成，用 . 连接：header.payload.signature

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4ifQ.sflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

3.3 详细解析

① Header（头部）

json

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

alg 支持多种算法
- HS256：对称加密，同一个密钥进行签名和验证
- RS256：非对称加密，私钥签名、公钥验证
Base64 编码存储

② Payload（载荷）

json

{
  "sub": "1234567890",
  "name": "John",
  "iat": 1516239022
}

包含声明（claims），都是可选的
标准声明：iss（签发者）、exp（过期时间）、sub（主题）
Base64 编码，可被解码，不应存放敏感信息

③ Signature（签名）

签名 = HS256(
  base64(header) + "." + base64(payload),
  secret_key
)

使用指定算法对前两部分进行加密
保证令牌在传输过程中不被篡改

3.4 工作流程

3.5 适用场景

JWT 适合分布式架构、需要跨域认证、前后端完全分离的场景：

微服务架构：各服务独立部署，JWT 作为统一身份令牌，避免 Session 共享带来的分布式 session 问题
移动端 + Web 混合应用：iOS/Android/App 使用同一套 API，JWT 可被各端统一验证
第三方 API 授权：OAuth 2.0 开放授权场景（如 GitHub 登录、Google 登录），JWT 作为授权凭证
SSR + API 分离架构：前端 VitePress/Next.js，后端 Express/Koa，JWT 实现无状态认证

典型业务：SaaS 平台、移动应用后端、开放平台、GraphQL API 服务

3.6 前端存储与使用

typescript

// 存储在 localStorage
localStorage.setItem('token', jwt)

// 请求时携带
fetch('/api/user', {
  headers: {
    'Authorization': `Bearer ${localStorage.getItem('token')}`
  }
})

四、三者对比

维度	Cookie	Session	JWT
存储位置	客户端	服务器端	客户端
数据格式	字符串	任意格式	JSON
存储量	有限（4KB）	理论无限	较小
安全性	低（易获取/篡改）	高（仅暴露 ID）	中（签名防篡改）
服务器资源	不占用	占用内存	不占用
状态保持	自动携带	依赖 Cookie 传 ID	需手动携带
适用场景	简单状态、数据量小	高安全性、中小型应用	分布式架构、跨域认证

选型建议

Cookie：简单场景、用户偏好设置
Session：传统 Web 应用、需要高安全性
JWT：前后端分离、微服务架构、跨域认证

五、业务场景对比

场景一：用户登录后访问博客文章

推荐方案：Session

原因：

博客系统通常为单体应用，Session 可直接存储在内存或 Redis 中
用户登录状态需要服务端强控制，防止用户伪造身份发布评论
安全性要求适中，Session 足以满足

实现方式：用户登录后创建 Session，Session ID 通过 Cookie 传输，后续请求服务端验证 Session 有效性。

场景二：开放平台第三方登录授权

推荐方案：JWT

原因：

第三方应用通过 API 获取授权令牌，需支持跨域验证
授权服务器可能为独立服务，JWT 可被各业务服务独立验证
支持短期令牌 + refresh token 机制，可灵活控制授权时效

实现方式：授权服务器签发 JWT，各业务服务公钥验证，无需共享 Session。

场景三：电商网站购物车

推荐方案：Cookie

原因：

购物车数据简单（商品 ID、数量），存储量小
用户可能未登录就添加商品，Cookie 可跨会话保持
不涉及敏感支付信息，Cookie 丢失影响可控

实现方式：将购物车 JSON 数据加密后存入 Cookie，提交订单时发送到服务端合并。

场景四：银行后台管理系统

推荐方案：Session

原因：

涉及账户资金操作，必须服务端验证，任何客户端数据都不可信
管理员权限变更、审计日志等需要服务端强一致性
内网访问，用户量可控，Session 内存开销可接受

实现方式：Session 存储用户角色、权限、操作日志，服务端验证通过后才执行操作。

场景五：移动 App 调用后端 API

推荐方案：JWT

原因：

iOS/Android/Web 多端共用同一套 API，JWT 无状态验证更灵活
无 Cookie 概念，JWT 通过 Authorization Header 传递
服务端可水平扩展，无需 Session 同步

实现方式：登录成功后返回 JWT，客户端存储在设备 Keychain/Keystore，请求时携带。

场景六：前端静态站点 + 多个后端微服务

推荐方案：JWT

原因：

前端 VitePress/Next.js 与多个后端服务（用户服务、订单服务）分离部署
每个微服务独立验证 JWT，无需共享 Session 存储
支持跨域调用，API 网关可统一鉴权后转发

实现方式：API 网关统一验证 JWT 签名，验证通过后附加用户信息转发给下游服务。

场景对比总结

场景	推荐方案	关键考虑因素
博客网站用户登录	Session	单体应用、安全性适中
开放平台授权	JWT	跨域验证、无状态
电商购物车	Cookie	数据简单、跨会话
银行后台管理	Session	高安全性、强控制
移动 App API	JWT	多端共用、水平扩展
微服务架构	JWT	分布式验证、跨域

六、常见问题

Q：Session 和 JWT 哪个更安全？

Session 更安全，因为用户数据存在服务器，仅暴露 ID。而 JWT 的 Payload 是 Base64 编码，可被解码，敏感信息需加密存储。

Q：JWT 如何实现注销？

由于 JWT 是自包含的，服务器无法主动销毁。方案包括：

黑名单机制（存储已注销的 token）
缩短 token 有效期
使用 refresh token 机制

总结

三种认证方式各有优劣，实际项目中往往需要组合使用。理解它们的原理和适用场景，才能做出合理的技术选型。

深入理解 Cookie、Session、JWT 的原理、实现和区别 ​

前言 ​

一、Cookie ​

1.1 原理 ​

1.2 工作流程 ​

1.3 优缺点 ​

1.4 适用场景 ​

二、Session ​

2.1 原理 ​

2.2 工作流程 ​

2.3 优缺点 ​

2.4 适用场景 ​

三、JWT（JSON Web Token） ​

3.1 原理 ​

3.2 组成结构 ​

3.3 详细解析 ​

3.4 工作流程 ​

3.5 适用场景 ​

3.6 前端存储与使用 ​

四、三者对比 ​

选型建议 ​

五、业务场景对比 ​

场景一：用户登录后访问博客文章 ​

场景二：开放平台第三方登录授权 ​

场景三：电商网站购物车 ​

场景四：银行后台管理系统 ​

场景五：移动 App 调用后端 API ​

场景六：前端静态站点 + 多个后端微服务 ​

场景对比总结 ​

六、常见问题 ​

总结 ​

深入理解 Cookie、Session、JWT 的原理、实现和区别

前言

一、Cookie

1.1 原理

1.2 工作流程

1.3 优缺点

1.4 适用场景

二、Session

2.1 原理

2.2 工作流程

2.3 优缺点

2.4 适用场景

三、JWT（JSON Web Token）

3.1 原理

3.2 组成结构

3.3 详细解析

3.4 工作流程

3.5 适用场景

3.6 前端存储与使用

四、三者对比

选型建议

五、业务场景对比

场景一：用户登录后访问博客文章

场景二：开放平台第三方登录授权

场景三：电商网站购物车

场景四：银行后台管理系统

场景五：移动 App 调用后端 API

场景六：前端静态站点 + 多个后端微服务

场景对比总结

六、常见问题

总结