javascript 不管理 session，需后端统一存储（如 redis）并前端配合传递凭证、响应失效、校验会话，跨域依赖认证中心协调，登出须全局通知。

JavaScript 本身不管理 Session，Session 是服务器端机制；前端无法直接“同步”集群中的会话数据，只能配合后端方案维持登录态的一致性。关键在于：让多个服务器共享同一份会话状态，而 JS 负责正确传递凭证、响应失效、避免视图层与真实状态脱节。

用统一存储替代本地内存

集群中每台服务器不能各自保存 Session 到自己的内存里。必须把 Session 数据外置到所有节点都能访问的中心化存储中：

• 推荐 Redis：高性能、支持过期、天然分布式，Spring Session、Express-session 等主流框架都原生支持；写入一次，所有服务实例实时可读
• 数据库（如 MySQL）也可行，但频繁读写会拖慢响应，仅适合低并发或对一致性要求极高的场景
• 避免 Session 复制（广播同步）——节点增多时网络开销剧增，易引发延迟和内存溢出

前端只负责安全传递和及时响应

JS 不生成或修改 Session，但要确保凭证不丢失、不失效、不误用：

Ai Coach Batch Session Summary

批量分析录音转写，输出多维度拓客报告。触发词：录音分析、总结、音频总结、拜访记录总结。当用户提及「分析录音」「看看录音数据」「最近的录音」「通话记录」且意图为批量统计/分析时触发。仅出现「录音」或「拜访」时需结合上下文，若仅查看单条详情则不触发。

下载

• 登录成功后，后端应设置 HttpOnly + Secure + SameSite=None 的 Cookie（若跨子域），或返回 JWT 存入 localStorage（需自行管理刷新逻辑）
• 所有 API 请求拦截器中检查响应状态码：401 或 403 时立即清空本地用户信息、跳转登录页
• 页面切回前台（visibilitychange）、或定时（如每 5 分钟）调用轻量接口（如 /auth/me）校验会话是否仍有效

跨域或多系统时靠认证中心协调

如果集群包含不同域名的子系统（如 shop.example.com 和 pay.example.com），Cookie 无法自动共享：

• 统一使用一级域名（如 .example.com）部署所有服务，并将认证中心设为该域下，Cookie 才能被各子域读取
• 若必须跨主域，改用 Token + 后端透传：前端携带 token，后端在请求头中转发给其他系统，由对方后端独立校验
• 禁用前端直接操作其他域 Cookie 的想法——浏览器策略不允许，只能由后端在同源请求中注入或清理

登出必须全局通知，不能只清前端

单点登出（SLO）不是 JS 清 localStorage 就完事：

• 登出请求必须发往统一认证中心（如 POST /auth/logout），由中心使 token 失效、清理 Redis 中的 Session
• 认证中心需主动通知其他系统（例如通过 Redis Pub/Sub、WebSocket 或异步 Webhook），各系统收到后清除本地缓存或标记会话过期
• 前端登出后，除清本地状态外，应等待后端回调确认全局登出完成，再跳转首页

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南