Session是服务端机制，前端JS无法直接操作，只能通过自动携带HttpOnly Cookie中的Session ID与后端协同维护会话状态，关键在于配置credentials、处理401响应及登出联动。
Session 本身是服务端机制，前端 JavaScript 无法直接“操作” Session，但可以通过 Cookie 或 Token 配合后端实现用户状态管理。在前后端分离架构中，关键不是“前端用 Session”，而是“前后端协同维护会话状态”。
Session 的本质和前端角色
Session 数据存在服务器内存、Redis 或数据库中，客户端只持有一个 Session ID（通常通过 HttpOnly Cookie 自动携带）。前端 JavaScript 一般不读写这个 ID，也不应手动传它——浏览器会在每次请求时自动附带 Cookie（前提是配置了 withCredentials: true 和正确域名/路径）。
所以前端真正要做的：确保请求能带上凭证、处理登录/登出逻辑、响应会话过期提示。
前后端配合的关键配置
-
后端设置 Cookie 安全属性：设
HttpOnly=false（如需 JS 读取，但通常不需要）；Secure=true（HTTPS 环境）；SameSite=Lax或Strict（防 CSRF）；Path=/确保所有接口都能携带 -
前端请求开启凭据支持：Axios 示例：
axios.defaults.withCredentials = true；Fetch 示例：fetch(url, { credentials: 'include' }) -
跨域需明确允许：后端响应头加
Access-Control-Allow-Credentials: true，且Access-Control-Allow-Origin不能为*，必须指定具体域名（如https://your-fe.com）
常见场景的处理方式
登录成功：前端发 POST 请求到 /login，后端验证后创建 Session 并写入 Cookie。前端无需保存 Session ID，后续请求自动携带。
立即学习“Java免费学习笔记（深入）”；
创建全面的交接文档，使新AI代理能够无缝继续工作，消除歧义。解决上下文耗尽问题。 时机：(1)用户请求保存交接，(2)上下文即将满，(3)主要任务完成，(4)会话结束，(5)恢复工作时。 关键词：保存状态、创建交接、上下文已满、暂停、从...恢复、加载交接、保存进度、会话转移、交接
接口鉴权失败（401/403）：后端检测 Session 无效或过期，返回对应状态码。前端拦截响应，在 axios 的 response.interceptors 中跳转登录页或清空本地缓存。
主动登出：前端调用 /logout 接口，后端销毁 Session；前端可清空可能存在的 token 缓存（如 localStorage），但不必操作 Cookie（浏览器会继续发送，直到服务端不再识别）。
替代方案：为什么有人用 Token？
Session 依赖 Cookie，在某些场景（如移动端 WebView、跨子域复杂、需自定义凭证）下不如 JWT 灵活。但 Session 更安全（天然防 XSS 泄露 ID）、易失效、支持服务端强管控。选型不看“流行”，而看是否需要：
- 服务端主动踢人？→ Session 更合适
- 多终端统一登录态？→ Session + 统一域名或共享 Cookie 域名
- 纯静态部署、无 Cookie 支持环境？→ 改用 Token + 手动携带 Authorization 头
不复杂但容易忽略细节，核心就是让 Cookie 能正确发送、服务端能识别、异常有反馈。
