本文为个人总结，如有错误请评论区指出

Cookie

Cookie 是服务器下发、由客户端存储并在后续请求中自动携带的小型文本数据，核心作用是在无状态的 HTTP 协议之上，实现客户端与服务器间的状态持久化

Cookie数据格式

是键值对的文本字符串，
如：sessionId=wzxg123

Cookie的特性

1. 服务器控制：Cookie由服务器通过响应头的Set-Cookie指令下发，客户端只能被动接收
2. 自动携带：符合域名 / 路径 / 有效期规则时，浏览器会在请求头的 Cookie 字段中自动携带，无需开发者手动处理

Cookie的生命周期

1. 下发：客户端登录成功后，服务器在响应头中添加Set-Cookie指令

如：

Set-Cookie: sessionId=wzxg123;Path=/;Domain=wzxg.com;Max-Age=60

2. 存储：客户端浏览器接收响应，解析Set-Cookie，按规则将Cookie存储在本地

3. 回传：客户端后续请求时，浏览器自动在请求头中携带Cookie

还是上面那个例子：

Cookie: sessionId=wzxg123

4. 失效/删除：Cookie过期后会失效被自动删除，也可以手动删除

• 过期失效自动删除：通过Max-Age(秒)或Expires(GMT时间)设置有效期
• 手动删除：浏览器设置中清除Cookie，或服务器通过 Set-Cookie 下发和原 Cookie 完全一致的 Domain、Path、Key，仅将有效期设为过去值

Set-Cookie的关键属性

属性	作用	例子
Name=Value	Cookie 的键值对，核心数据	sessionId=wzxg123
Domain	限定 Cookie 生效的域名（子域名可继承）	Domain=wzxg.com
Path	限定 Cookie 生效的路径	Path=/user
Max-Age	有效期（秒），优先级高于 Expires	Max-Age=60（60秒）
Expires	过期时间（GMT 格式），用于兼容旧浏览器	Expires=Mon, 12 Jan 2026 08:00:00 GMT(2026 年 01 月 12 日 星期一)
HttpOnly	禁止 JavaScript 读取 Cookie	加上HttpOnly即可

Session

Session是服务器端专门用来存储客户端用户的会话状态数据的缓存对象，本质是服务端的状态容器。核心作用是在无状态的 HTTP 协议中，让服务器能记住某个客户端的身份和状态解决 HTTP 无状态。

Session工作流程

1. 客户端发起第一次请求（比如访问无籽西瓜 GET /wzxg）

• HTTP 是无状态的，请求头里没有任何身份凭证；
• 服务器收到请求，发现「这个客户端没有对应的 Session」；

2. 服务器创建 Session+ 生成SessionId

• 服务器在内存 / 缓存（Redis）中，创建一个全新的 Session 对象（本质是一个键值对容器，比如{userId:wzxg, username:“无籽西瓜”, role:“admin”}）；
• 服务器为这个 Session 生成一个唯一的、随机的、无意义的字符串→ SessionId（比如 sessionId=df2a9s7d6f5g41jdoiaj1），这个值是服务器生成的，无法伪造；

3. 服务器通过Set-Cookie下发 SessionId 到客户端

• 服务器在响应头中，通过 Set-Cookie 指令，把这个 SessionId 下发给浏览器

如：

    Set-Cookie: sessionId=df2a9s7d6f5g41jdoiaj1; 
     Domain=wzxg.com;
     Path=/; Max-Age=60; 
     HttpOnly;

4. 浏览器存储 SessionId 的 Cookie

• 浏览器收到响应头的Set-Cookie，会把这个sessionId=wxzg的 Cookie 存储在本地；
• 这个 Cookie 的唯一作用：就是帮客户端记住这个 SessionId

5. 客户端发起后续所有请求（比如查无籽西瓜的价格 GET /wxzg/price）

• 浏览器发起请求时，会自动校验 Cookie 的规则：域名匹配、路径匹配、有效期内；
• 满足规则后，浏览器会在请求头中自动携带这个 Cookie，无需开发者手动处理：

    Get /wzxg/price
    Host: wzxg.com
    Cookie: sessionId=df2a9s7d6f5g41jdoiaj1

6. 服务器通过 SessionId 找到 Session，实现状态识别

• 服务器从请求头的 Cookie 中，解析出sessionId的值；
• 服务器拿着这个值，去自己的内存 / 缓存中查，找到对应的 Session 对象；
• 服务器从 Session 中读取用户的状态数据（userId、username、role），然后处理业务逻辑，返回对应的数据；
  整个过程，服务器无需查数据库，无需重新验证用户身份，效率极高

Session特性

1. Session 是服务端存储，安全可靠

• 所有用户的核心数据都存在服务器，客户端只存一个无意义的 SessionId；
• 客户端无法篡改 Session 里的数据，也无法伪造 SessionId（因为是服务器生成的随机字符串），安全性远高于 Cookie；

2. Session 是用户专属，互不干扰

• 每个客户端的 SessionId 都是唯一的，服务器会为每个客户端创建独立的 Session 对象

3. Session有过期时间，会自动失效

• Session 不是永久存在的，服务器会给 Session 设置过期时间

Token

Token（令牌）是服务端签发的、用于身份验证与授权的、带签名 / 加密的字符串凭证，核心作用是在无状态的 HTTP 协议中，安全地传递用户身份与权限信息，替代传统 Cookie+Session 方案，尤其适合分布式、跨域、移动端场景

Token特性

1. 自包含：令牌本身可携带用户 ID、角色、权限、有效期等核心信息，服务端无需存储会话数据（无状态）
2. 防篡改： 过签名（如 JWT 的 HS256/RS256）或加密，确保令牌内容无法被恶意修改，验证失败则直接拒绝
3. 短期有效：默认设置较短有效期，降低被盗用风险，配合刷新令牌机制实现长期登录
4. 传输安全：必须通过 https 传输，防止 Token 被中间人窃取；禁止在 URL 参数中携带 Token

Token工作流程

1. 服务端登录验证通过后，生成 Token，直接在响应体里返回 Token 字符串（不是 Set-Cookie 响应头）：

{
    "code": 200,
    "msg": "登录成功",
    "data": {
        "token": "xxx.xxx.xxx"
    }
}

2. 前端拿到这个 Token 字符串后，存入浏览器的 LocalStorage（长期存储）或 SessionStorage（会话存储，关闭浏览器消失）：

3. 前端在每次发起请求时，把 Token 放进 HTTP 请求头的自定义字段 里（最常用的是Authorization），格式固定：

Host: wxzg.com
Authorization: Bearer xxx.xxx.xxx
Content-Type: application/json

注意：Bearer 后面有一个空格，是标准写法，后端都会按这个规则解析

4. 服务器从请求头的Authorization字段中拿到 Token，做验证即可。

JWT

JWT 的全称是JSON Web Token，JWT 是 Token 的其中一种标准化、规范化的实现方式
是一种基于JSON、用于在网络中安全传输声明的开发标准，常用于无状态的身份认证和信息传递

（无状态是指服务器不会默认保留客户端的任何请求上下文信息，每个 HTTP 请求都是独立、自包含、与前后请求无关的，服务器处理请求时，仅依据当前请求自身携带的数据完成响应）

JWT的组成结构

JWT由三部分由.分隔的Base64编码字符串组成

• Header：声明令牌的类型和签名算法
  alg为签名算法
  typ为令牌类型

如：

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

• Payload：存储核心声明信息，分三类：
  • 注册声明：标准字段,如：sub(主题，用于表示这个JWT令牌的所有者)、exp（过期时间）等
  • 公共声明：自定义公共字段
  • 私有声明：自定义私有字段（如user_Id）

如：

{
	"sub": "2331680694",
	"name": "wzxg",
	"exp":"1768218279",
	"user_Id":"wzxg233"
}

• Signature：对Header和Payload的Base64编码结果，用指定算法和密钥生成

JWT工作流程

1. 客户端发起登录请求

2. 服务端验证身份并生成 JWT

• 服务端校验账号密码、权限等信息，验证通过后，准备 JWT 的三个核心部分

  • Header：声明算法与令牌类型，JSON 转 Base64Url 编码

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

  • Payload：存储标准声明（exp 过期时间、sub 用户 ID 等）与自定义业务数据（如角色、权限），JSON 转 Base64Url 编码

  {"sub":"wzxg233","name":"wzxg","exp":1768218279,"role":"admin"}
  

  • Signature：用密钥对 Base64Url(Header)+“.”+Base64Url(Payload) 进行加密，防止数据篡改

  HS256(
      base64UrlEncode(header) + "." + base64UrlEncode(payload),
      密钥（如"wxzg-secret-key"，必须保密）
  )
  

• 拼接三段 Base64Url 编码字符串（用.分隔），生成完整 JWT 令牌

• 服务端在响应体中返回 JWT（不使用 Set-Cookie，无状态核心体现）

{
    "code":200,
    "msg":"登录成功",
    "data":{
        "accessToken":"xxx.xxx.xxx",
        "refreshToken":"yyy.yyy.yyy",
        "expireIn":600
    }
}

3. 客户端存储 JWT 令牌

4. 客户端携带 JWT 发起后续请求
前端每次请求时，手动在请求头的Authorization字段中携带 JWT，格式为Bearer 空格 JWT字符串

5. 服务端验证 JWT 令牌

• 服务端提取请求头中的Authorization字段，分离出 JWT 字符串
• 验证流程（Java 后端常用 JJWT 框架实现）
  • 校验格式：是否为三段式、Base64Url 编码是否合法
  • 校验签名：用相同密钥和算法重新计算签名，与 JWT 的 Signature 部分比对，不一致则令牌被篡改，拒绝请求
  • 校验有效期：检查exp字段是否大于当前时间，过期则拒绝请求
• 验证通过后，解析 Payload 中的用户信息，用于业务逻辑处理

6. 令牌过期与刷新

• accessToken过期后，服务端返回 401
• 客户端用refreshToken发起刷新请求

Host: wzxg.com
Authorization: Bearer yyy.yyy.yyy

• 服务端验证refreshToken通过后，生成新的accessToken并返回
• 客户端用新的accessToken继续请求，用户无需重新登录