前端路由不管理Session，关键在请求配置、Cookie传递与后端会话维护；需正确设置credentials、域名匹配、负载均衡策略及跨域响应头，或采用Token映射替代Cookie。
前端路由本身不管理 Session，它只是控制页面展示逻辑；真正影响分布式 Session 能否正常工作的，是请求发起方式、Cookie 传递机制，以及后端如何统一维护会话状态。关键不在“前端路由怎么配”，而在于“请求怎么发、Cookie 怎么带、后端怎么认”。
前端路由不干预会话，但请求配置必须正确
Vue Router 或 React Router 这类前端路由切换页面时，若只是渲染组件、不触发新请求，则不会涉及 Session。一旦发起 API 请求（比如调用 /api/user/info），就必须确保：
- 使用
fetch时设置credentials: 'include' - 使用
axios时开启withCredentials: true - 请求 URL 的域名和端口，需与后端 Set-Cookie 所声明的
domain和path匹配
负载均衡器要支持会话保持或无状态转发
如果后端用了 Redis 存储 Session（如 Spring Session），负载均衡器就无需做会话黏性；它可自由轮询分发请求，所有节点都能从 Redis 查到同一份 JSESSIONID 对应的数据。
- 推荐关闭 Nginx 的
ip_hash，避免因用户 IP 变化导致会话中断 - 若暂时没上 Redis，又必须用多实例，才考虑启用
cookie模式（如 Nginx 的sticky cookie），让 LB 自动在响应中写入路由标识 - 注意：这种 Cookie 是 LB 自己加的（如
route=server1），和应用层的JSESSIONID无关，不能替代分布式 Session
跨域场景下 Cookie 无法自动携带，必须双向配合
前端运行在 http://localhost:3000，后端 API 在 http://api.example.com:8080，这就是典型跨域——浏览器默认不发 Cookie。
立即学习“Java免费学习笔记（深入）”；
- 后端需返回
Access-Control-Allow-Credentials: true - 同时
Access-Control-Allow-Origin不能为*，必须明确写出前端域名（如http://localhost:3000） - 前端请求头不能省略
credentials配置，否则浏览器直接忽略 Cookie - 更稳妥的做法是开发期用 Nginx 反向代理，把
/api/前缀代理到后端，使请求变同源
Session ID 的传递不止靠 Cookie，也可用 Token 映射
当 Cookie 路径受限（如小程序、App、第三方调用），可由后端生成一个短期有效的 Token，该 Token 内部映射到真实的 JSESSIONID，并存于 Redis。
- 登录成功后，后端返回
{ token: "abc123" }，前端存在 localStorage - 后续请求在
Authorization: Bearer abc123中携带 - 后端拦截器解析 Token，查 Redis 获取对应 Session 数据，再绑定到当前请求线程
- 这种方式绕过 Cookie 限制，也便于前后端分离部署
