javascript中session在前后端分离架构里不能直接替代cookie校验，而是用token机制实现等效会话管理：登录后前端存token于localstorage，请求时手动携带到authorization头，后端通过过滤器校验token并注入安全上下文，避免依赖jsessionid和自动cookie机制。
JavaScript中Session在前后端分离架构里不能直接“替代”Cookie校验，而是要绕过Cookie依赖，用Token机制实现等效的会话状态管理。关键不是复刻Session行为，而是用更可控、跨域友好的方式完成身份识别和状态延续。
Token代替JSESSIONID：前端自己管凭证
传统Session靠服务器发JSESSIONID Cookie，浏览器自动携带；前后端分离时，这个链路断了——因为跨域默认不传Cookie，且App、小程序根本不支持自动Cookie管理。所以得把“会话标识”变成前端可主动读写、手动携带的数据：
- 登录成功后，后端返回JWT或自定义Token（如
accessToken），前端存入localStorage或sessionStorage - 后续所有API请求，统一在
Authorization请求头中带上：Bearer xxxxx - 不再依赖
Set-Cookie响应头，也不指望浏览器自动回传任何会话标识
后端验证逻辑要重写：从查Session转为验Token
后端不能再调request.getSession()或依赖Spring Security的默认Session拦截器。必须改用Token解析与校验流程：
- 加一个全局过滤器或Spring Boot的
OncePerRequestFilter，提取Authorization头中的Token - 用密钥验证签名（JWT）或查Redis缓存（自定义Token），确认未过期、未被撤销
- 解析出用户ID、角色等信息，塞入
SecurityContext或自定义上下文，供业务逻辑使用 - 拒绝所有没Token、Token无效或过期的请求，返回
401
避免“伪Session”陷阱：不存敏感数据在前端
有人试图把用户权限、手机号等直接存在localStorage里，再配合简单时间戳做“简易Session”，这是危险的：
-
localStorage可被任意脚本读取，XSS攻击下极易泄露 - 没有服务端控制力，无法主动使Token失效（比如用户改密码后踢掉旧登录）
- 建议只存Token本身，所有用户状态（权限、组织、有效期）均由后端Token载荷（Payload）或Redis实时校验决定
需要时仍可兼容Cookie（但非必须）
如果团队坚持用Spring Session + Redis，也不是完全不可行，只是配置更重：
- 后端CORS必须设
Access-Control-Allow-Credentials: true - 前端fetch/axios请求必须带
credentials: 'include' - 前后端域名需同源，或后端明确列出前端域名到
allowedOrigins - 浏览器对
localhost:3000 → localhost:8080这种端口不同也算跨域，必须显式放行
这条路能复用原有Session代码，但牺牲了灵活性和移动端适配能力，适合内部系统快速迁移，不适合对外产品或混合客户端场景。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
