在服务端维持登录会话，主流有两种方案：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 机制：
- 登录成功后，服务器会给浏览器种下
JSESSIONIDCookie； - 后续请求（如版块列表、留言查询），浏览器 / Postman 会自动携带该 Cookie；
- 服务器通过
JSESSIONID识别用户会话，无需前端手动处理，完全符合传统 Web 开发规范。
三、Token 方案是什么场景？
项目的接口适配前后端分离 / 跨端架构（如 APP、小程序）：
- 后端不依赖 Session，登录成功后返回 Token（如 JWT）；
- 前端需手动将 Token 放入请求头（如
token: xxx），后续请求携带该请求头； - 服务器通过 Token 校验用户身份，适配多端（Web/APP/ 小程序）场景。
四、Postman 中的使用要点
- Cookie 方案：只需先发送登录请求，后续请求会自动携带 Cookie，无需额外配置，和浏览器逻辑一致。
- Token 方案 ：登录后从响应中复制 Token，在后续请求的 Headers 中添加自定义头（如
token: {你的Token值}）。