博客会话维持方式总结

在服务端维持登录会话，主流有两种方案：Cookie/Session 和 Token（如 JWT），二者只是实现方式不同，没有好坏之分，核心区别与适用场景如下：

---

一、两种方案核心对比

对比项	你的 Cookie/Session 方案	老师的 Token（Header）方案
原理	服务器给浏览器下发 JSESSIONID Cookie，后续请求自动携带，服务器通过该 ID 匹配用户会话	登录成功后服务器返回 Token（如 JWT），后续请求需手动将 Token 放入请求头，服务器通过 Token 识别用户身份
数据位置	请求头的 Cookie 字段中	自定义请求头（如 token / Authorization）
适用场景	传统 Web 应用（浏览器会自动处理 Cookie）	前后端分离项目、移动端 / 小程序（无原生 Cookie 机制）
Postman 用法	登录后自动维护会话，后续请求无需手动配置	登录接口获取 Token 后，需复制到 Headers 中手动配置

---

二、项目为什么用 Cookie/Session？

项目是传统 Web 应用 ，后端采用 Java HttpSession 机制：

1. 登录成功后，服务器会给浏览器种下 JSESSIONID Cookie；
2. 后续请求（如版块列表、留言查询），浏览器 / Postman 会自动携带该 Cookie；
3. 服务器通过 JSESSIONID 识别用户会话，无需前端手动处理，完全符合传统 Web 开发规范。

---

三、Token 方案是什么场景？

项目的接口适配前后端分离 / 跨端架构（如 APP、小程序）：

1. 后端不依赖 Session，登录成功后返回 Token（如 JWT）；
2. 前端需手动将 Token 放入请求头（如 token: xxx），后续请求携带该请求头；
3. 服务器通过 Token 校验用户身份，适配多端（Web/APP/ 小程序）场景。

---

四、Postman 中的使用要点

• Cookie 方案：只需先发送登录请求，后续请求会自动携带 Cookie，无需额外配置，和浏览器逻辑一致。
• Token 方案 ：登录后从响应中复制 Token，在后续请求的 Headers 中添加自定义头（如 token: {你的Token值}）。