javascript本身不处理分布式session一致性，前端只传递凭证（如自动携带cookie中的session id），不维护状态逻辑；须配合后端redis等集中存储、正确配置cors凭据、samesite与domain，以及sso统一认证机制实现多系统状态同步。
JavaScript 本身不处理分布式 Session 的一致性——Session 是服务端机制，前端无法也不应直接管理或同步它。所谓“JS 中处理”，实际是指前端如何配合后端方案，确保用户状态在多节点、跨域、多系统场景下表现一致、不掉线、不越权。
核心原则：前端只传递凭证，不维护状态逻辑
浏览器通过 Cookie 自动携带 session ID（如 JSESSIONID 或自定义名），这是唯一被服务端信任的会话标识。前端要做的是：
- 不手动读取、修改、存储或拼接 session ID —— 尤其避免用 localStorage 存 openid / userId 后再塞进 header，这绕过 Cookie 安全机制，易被篡改
- 不自行实现“前端 Session 管理器”来模拟登录态；Vuex/Pinia 中的 user state 只是视图缓存，必须和服务端实际 session 生命周期严格对齐
- 所有 API 请求由统一拦截器处理：检查响应状态码（401/403）、监听 token 过期时间、自动触发登出清理
配合集中式 Session（如 Redis）的关键动作
当后端采用 Spring Session + Redis 等方案统一存储 session 时，前端只需保障 Cookie 正确传输：
- 确保请求同源（或配置好 CORS + credentials: 'include'），使浏览器能自动带上含 session ID 的 Cookie
- 若涉及子域名（如 shop.example.com 和 api.example.com），后端需设置 Cookie domain=.example.com，且 SameSite=None; Secure
- 页面加载或重新获得焦点（visibilitychange）时，可轻量调用 /auth/me 接口校验当前 session 是否仍有效，避免“显示已登录但请求 401”
应对跨系统联合登录（SSO）的同步策略
多个业务系统共用一个认证中心时，前端不能靠 Cookie 共享（跨主域禁止），而要依赖后端协同和有限的前端通信：
- 登录页跳转至统一认证域（如 auth.example.com/login），成功后重定向回原系统并附带 code 或 JWT
- 各系统嵌入隐藏 iframe 指向 auth.example.com/status，通过 postMessage 接收认证中心广播的登录态变更（如用户登出）
- 登出操作必须调用认证中心的登出接口（如 /auth/logout），由后端广播失效指令，前端收到消息后清空本地 store 并跳转
避开常见陷阱
很多状态不一致问题，根源不在分布式架构本身，而在前后端协作失当：
- 后端未设置 httpOnly=true、secure=true、sameSite=Strict（或 Lax/None 配合 domain），导致 Cookie 不被发送
- 前端在 axios 拦截器中错误地覆盖了 Cookie 头，或误设 headers: { 'Cookie': 'xxx' } —— 浏览器禁止 JS 设置 Cookie，只能由服务端 Set-Cookie 响应注入
- 开发环境启用了 localhost，但测试环境用了 127.0.0.1，二者被视为不同源，Cookie 不共享
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
