Sticky Session由负载均衡器实现，非JavaScript完成；其原理是LB根据Cookie或IP等标识将同一用户请求固定路由至同一后端服务器，JavaScript仅负责携带Cookie及响应会话失效。
在负载均衡架构中，Sticky Session（粘性会话）不是 JavaScript 本身实现的，而是由后端基础设施（如 Nginx、HAProxy、云服务商 LB）或应用层框架配合完成的；JavaScript（尤其是浏览器端）只负责携带和发送会话标识（如 Cookie），不参与路由决策。
Sticky Session 的核心原理
负载均衡器根据客户端某个稳定标识（最常见的是 Session ID 或 JSESSIONID/Cookie 值），将同一用户的后续请求始终转发到同一台后端服务器。这样避免了多实例间共享 session 数据的复杂性。
JavaScript 在这个过程里主要做两件事：发起请求时自动带上 Cookie；必要时读取/校验 session 状态（但不控制分发逻辑）。
前端 JavaScript 能做的配合事项
-
确保 Cookie 正确发送：使用
fetch或XMLHttpRequest时设置credentials: 'include'，否则浏览器不会发送 Cookie -
避免手动覆盖 Cookie：不要用
document.cookie覆盖服务端下发的 session cookie（如Set-Cookie: JSESSIONID=xxx; Path=/; HttpOnly） -
检查跨域配置：若前端与后端域名不同，需确认后端设置了
Access-Control-Allow-Credentials: true，且Access-Control-Allow-Origin不能为* -
识别会话失效场景：当 API 返回 401/403 或特定错误码（如
{ code: 4001, msg: "session expired" }），可触发重新登录，而不是静默重试
真正实现 Sticky Session 的地方
这是服务端/基础设施层的责任：
立即学习“Java免费学习笔记（深入）”；
-
Nginx 示例：用
ip_hash（基于客户端 IP）或hash $cookie_JSESSIONID consistent;（基于 Cookie 值哈希） -
HAProxy 示例：用
stick on cookie JSESSIONID+cookie JSESSIONID insert indirect nocache - 云服务（如 AWS ALB/NLB、阿里云 SLB）：开启“会话保持”，指定 Cookie 名称和超时时间
-
Spring Boot 应用：默认使用
JSESSIONID，配合上述 LB 配置即可生效；也可换用 Spring Session + Redis 实现无状态，此时就不依赖 Sticky Session
为什么不推荐纯靠 Sticky Session？
它会带来单点风险和扩容瓶颈：
- 某台服务器宕机，其上的 session 全部丢失（除非有持久化机制）
- 无法做到真正的水平扩展——流量无法均匀打散
- 滚动发布时，用户可能因 session 过期被强制登出
更现代的做法是：后端采用 无状态设计 + 外部 session 存储（如 Redis、数据库），让任意实例都能读写 session，从而关闭 Sticky Session，提升可用性与弹性。
