JavaScript无法直接实现Session，真正的Session管理必须由后端完成；多服务器下需将Session存至Redis等共享存储，前端只需正确携带Cookie或Token凭证。
JavaScript 本身（运行在浏览器端）不直接实现 Session，它只能通过 Cookie、localStorage 或 fetch/axios 发送请求来 使用 Session；真正的 Session 管理必须由后端完成。多服务器负载均衡下要保持会话一致，关键不是前端怎么写 JS，而是后端如何设计 Session 存储与分发机制。
Session 不应存在单台服务器内存中
默认的内存式 Session（比如 Express 的 express-session 配合内存存储）在多实例部署时完全失效：用户第一次请求被 A 服务器处理并创建 Session，第二次请求若被 Nginx 转发到 B 服务器，B 找不到该 Session，就会视为未登录。
解决方法是把 Session 数据抽离出来，统一存到外部共享存储：
- Redis：最常用，高性能、支持过期、可集群，适合绝大多数场景
- Memcached：轻量，但不支持复杂数据结构和持久化
- 数据库（如 PostgreSQL/MySQL）：可靠性高，但性能不如 Redis，适合对一致性要求极高、且 Session 读写不频繁的系统
- 集中式 Session 服务（如 Spring Session + Redis）：适合 Java 生态，本质仍是外置存储
前端 JavaScript 只需正确携带凭证
浏览器端 JS 不需要“实现”负载均衡逻辑，只需确保每次请求都带上服务端认可的身份凭证：
立即学习“Java免费学习笔记（深入）”；
批量分析录音转写，输出多维度拓客报告。触发词：录音分析、总结、音频总结、拜访记录总结。当用户提及「分析录音」「看看录音数据」「最近的录音」「通话记录」且意图为批量统计/分析时触发。仅出现「录音」或「拜访」时需结合上下文，若仅查看单条详情则不触发。
- 如果后端用 Cookie + HttpOnly Session ID（推荐），JS 无需手动操作，浏览器自动随请求发送 Cookie（注意确保前后端域名、path、Secure/HttpOnly 属性一致）
- 如果后端用 Token（如 JWT），JS 需在请求头中携带：
Authorization: Bearer xxx，此时 Session 状态实际已无状态化，负载均衡天然支持 - 避免用 localStorage 存 Session ID 后手动拼进 URL 或 body —— 不安全且易出错
负载均衡器需配合做会话粘滞（可选，不推荐作为主方案）
某些场景下（如遗留系统改造困难），可在 Nginx 或云 LB 层开启 IP Hash 或 Cookie 植入（sticky session），强制同一用户后续请求落到同一台后端。
但这只是临时缓解，并非真正解耦：
- 节点故障会导致会话丢失（除非 Session 本身已外置）
- 无法实现弹性扩缩容下的均匀流量分发
- 可能造成负载不均（比如某 IP 下大量用户）
所以仅建议作为兜底策略，核心仍应依赖外置 Session 存储。
Node.js 示例：Express + Redis 实现共享 Session
后端代码示意（前端 JS 完全不用改）：
const session = require('express-session');
const RedisStore = require('connect-redis')(session);
const redisClient = require('redis').createClient();
app.use(session({
store: new RedisStore({ client: redisClient }),
secret: 'your-secret-key',
resave: false,
saveUninitialized: false,
cookie: {
secure: true, // HTTPS only
httpOnly: true, // 防 XSS
sameSite: 'lax' // 防 CSRF
}
}));
部署多个 Express 实例，共用同一个 Redis 实例，Session 即自动跨服务器生效。前端所有 fetch 或 axios 请求照常发送，浏览器自动带 Cookie，后端从 Redis 读取即可。
