基于Cookie的会话保持能解决状态丢失，因其利用浏览器自动携带Cookie的特性，使负载均衡器通过首次响应注入或重写含服务器标识的Cookie，后续请求据此将同一用户始终路由至原服务器，复用其内存Session，避免登录态和购物车丢失。
负载均衡接入后，用户请求被轮询分发到不同后端服务器，导致登录态、购物车等状态丢失。解决这个问题的核心，是让同一用户的多次请求始终落到同一台后端服务器上——会话保持（Session Stickiness）正是为此设计，而基于 Cookie 的机制是最常用、最轻量、兼容性最好的方式。
为什么 Cookie 会话保持能解决状态丢失
HTTP 本身是无状态协议，但业务需要跨请求维持上下文。Cookie 由服务器下发、浏览器自动携带，天然适合作为“路由凭证”。负载均衡器不修改业务逻辑，只在首次响应中注入一个标识（如 srv_id 或重写 JSESSIONID），后续请求带着这个 Cookie 到来时，它就能准确识别并转发到最初处理该用户的那台服务器，从而复用内存中的 Session 数据，避免重复登录或数据错乱。
两种主流 Cookie 处理方式怎么选
植入 Cookie（Insertion）：负载均衡器主动生成并插入新 Cookie（如 ALB 的 SERVERID），适用于无法改动应用代码的遗留系统。优势是零侵入，且自带 SameSite=None，天然支持跨域场景。
重写 Cookie（Rewrite）：当应用已返回 Set-Cookie（如 Spring Boot 的 JSESSIONID），负载均衡器将其值替换成含服务器标识的新值。适合新建系统或可改造的应用，能复用原有会话生命周期管理逻辑。
选择依据很简单：能改代码就用重写；不能改、或要快速上线，就用植入。
关键配置要点不能漏
-
Cookie 属性要配全：尤其是 Path（建议设为
/）、Domain（匹配前端访问域名）、Max-Age（建议 1 小时起，避免过期失效） -
跨域场景必须补 SameSite 和 Secure：现代浏览器默认阻止跨域 Cookie，需显式设置
SameSite=None; Secure，且服务必须走 HTTPS -
注意 Path 匹配问题：如果后端返回
Path=/api，但前端访问路径是/admin，浏览器不会发送该 Cookie。Nginx 下可用proxy_cookie_path / "/";统一修正 - 避免依赖 IP 哈希：NAT、代理、移动端 IP 变更都会导致会话中断，Cookie 方案不受这些影响
Java 应用侧配合建议
Spring Boot 项目无需大改，只需确保 Cookie 设置合理：
- 登录成功后，用
response.addCookie(...)显式下发会话 Cookie - 设置
setHttpOnly(true)防 XSS，setSecure(true)强制 HTTPS - 不要硬编码 Domain，建议用配置项动态填入（如
example.com），便于多环境部署 - 若使用 Redis 存 Session，会话保持仍建议开启——它减少跨节点读取延迟，提升首屏响应速度
