| 组合方式 | 角色分工 | 适用场景 |
|---|---|---|
| SessionID + Cookie | SessionID 是身份凭证，Cookie 是传输载体 | 传统服务端渲染网站 |
| Token + Cookie | Token 是身份凭证，Cookie 是传输载体 | 前后端分离（追求安全） |
| Token + LocalStorage | Token 是身份凭证，LocalStorage 是存储载体 | 前后端分离（简单场景） |
前两个场景中服务器返回都是放在响应头，setcookie：sessionid=或token，所以请求头也是cookie:sessionid=或token
第三种是仅限token，放在响应体中如{code:200, token:"xxx"}），然后是存放在LocalStorage，请求时通过程序从LocalStorage取出变成请求头Authorization: Bearer xxx
sessionid和token可以理解为变量名：身份令牌或凭证
JWT是一种格式，签名格式，一般给token使用
cookie是任何时候都会和服务器传输，localstorage是看情况
需要和服务器交互（身份验证、状态同步）→ 选 Cookie（尤其是敏感凭证）；
纯前端使用、无需传给服务器、数据量稍大 → 选 LocalStorage（仅限非敏感数据）；
敏感数据（登录凭证）→ 优先选带 HttpOnly/Secure 的 Cookie，绝对不选 LocalStorage；
需要自动过期 → 选 Cookie，LocalStorage 需手动实现过期逻辑（麻烦）。
场景 1：SessionID 通过 Cookie 传输（最典型）
这里的 “传输” 分两步，全程由浏览器自动完成，不用开发者手动干预：
服务器→客户端（传输 SessionID）：你登录美业网站成功后，服务器生成 SessionID（如sess_123），然后在响应头里加Set-Cookie: sessionid=sess_123; Path=/ —— 这就是服务器把 SessionID “传输” 给客户端的过程（通过响应头的 Cookie 字段）。浏览器收到后，自动把 SessionID 存在 Cookie 里，完成 “接收”。
客户端→服务器（传输 SessionID）：你点击 “我的订单”，浏览器发请求时，会自动把 Cookie 里的sessionid=sess_123放到请求头的 Cookie 字段里 —— 这就是客户端把 SessionID “传输” 给服务器的过程。服务器收到请求头，取出 SessionID，验证后返回你的订单数据。
✅ 关键：这个 “传输” 是自动的，开发者不用写任何代码，浏览器帮你完成 “搬运”。
场景 2：Token 通过 Cookie 传输（和 SessionID 逻辑一致）
“传输” 过程和 SessionID 完全一样，只是凭证换成了 Token：
服务器生成 JWT Token（如eyJhbGciOiJIUzI1Ni...），通过响应头Set-Cookie: token=xxx; HttpOnly; Secure传输给浏览器；
浏览器后续请求时，自动把 Token 通过请求头的 Cookie 字段传输给服务器。
✅ 特点：同样是自动传输，且加了HttpOnly后，Token 不会被 JS 窃取，更安全。
场景 3：Token 通过 LocalStorage + 请求头 传输（手动传输）
LocalStorage 本身不能直接传输数据（它只是前端的 “储物柜”），所以需要结合请求头完成 “传输”，这个过程需要开发者手动写代码：
服务器→客户端（传输 Token）：登录成功后，服务器不通过 Cookie，而是把 Token 放在响应体里返回（如{code:200, token:"xxx"}） —— 这是服务器把 Token “传输” 给客户端的过程（通过响应体）。前端收到后，用localStorage.setItem("token", "xxx")把 Token 存在 LocalStorage 里（只是 “存起来”，还没完成 “向服务器传输”）。
客户端→服务器（传输 Token）：你请求 “我的测肤报告” 时，前端需要手动从 LocalStorage 取出 Token，然后放到请求头里（如Authorization: Bearer xxx） —— 这是开发者手动把 Token “传输” 给服务器的过程（通过请求头的自定义字段）。服务器收到请求头，取出 Token 验证，才返回数据。
✅ 关键：这个 “传输” 是手动的，LocalStorage 只负责 “存 Token”，真正的 “传输” 靠请求头完成。