HTTP 协议本身是无状态的。客户端发送一个请求，服务器处理并返回响应；下一次请求到来时，服务器不会天然知道它是否来自同一个用户。

这个特性简化了协议设计，却给登录、权限、购物车和多步表单带来了问题。

例如，用户先提交登录表单，服务器验证成功。随后用户访问订单页面，订单接口必须知道当前请求对应哪个账号。

如果每次请求都重新提交账号和密码，既不方便，也会扩大敏感信息暴露面。因此，应用需要一种机制，把“浏览器中的请求”与“服务器端保存的用户状态”关联起来。

Cookie 和 Session 经常一起出现，但它们解决的不是同一层问题。

• Cookie 是客户端保存并随请求发送的一小段数据。
• Session 通常是服务器端保存的状态记录。

理解两者的边界，是处理登录失效、跨域、集群部署和安全问题的基础。

工作原理

Cookie 如何参与请求

服务器可以在响应中发送 Set-Cookie：

HTTP/1.1 200 OKSet-Cookie: session_id=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

浏览器根据 Domain、Path、过期时间和安全属性保存这条记录。

之后访问匹配范围内的地址时，会自动携带：

Cookie: session_id=abc123

Cookie 的值会出现在客户端，因此不应直接放入密码、完整权限列表或其他高敏感数据。

常见做法是只保存一个不可预测的会话标识符，把真实状态留在服务器端。

Session 如何完成映射

服务端收到 session_id 后，可以从存储中读取对应记录：

session_id -> 用户身份、登录时间、权限摘要、过期时间

如果记录存在且未过期，应用就能把请求识别为已登录用户。

如果记录不存在、已过期或校验失败，则返回未登录状态。

单机应用里，把 Session 直接放进进程内存，做法很直观。

但短板也很明显：一旦进程重启，登录状态通常就没了；在多实例部署场景下，各个实例之间彼此隔离，也无法共享对方创建的会话。

把 Session 迁到 Redis 这类共享存储后，多个应用实例就能读取同一份会话数据，协同会顺畅很多。

不过，问题也不会凭空消失。网络超时、序列化开销、容量压力以及故障时的降级处理，都是绕不开的现实挑战。

Cookie 与 JWT 的边界

Cookie 是一种传输载体，JWT 是一种令牌格式，两者并非互斥。

JWT 可以放在 Authorization 请求头中，也可以放在 Cookie 中。

Session 方案的状态主要在服务端，便于主动注销和集中修改。

JWT 常把更多信息放到客户端，服务端校验时可以减少状态查询，但令牌签发后通常不容易立即撤销。

选择哪种方案取决于系统边界。

• 传统服务端页面、需要主动踢出用户或需要集中控制会话的系统，Session 往往更直接。
• 跨多个独立服务的接口体系，则需要进一步评估令牌验证、撤销和密钥轮换策略。

实现步骤

下面以 Spring Boot 应用为例，使用 Redis 保存 Session。

示例只展示关键配置，具体依赖版本应以项目当前的 Spring Boot 版本和依赖管理为准。

1. 添加依赖

Ma ven 中加入 Session 与 Redis 支持：

org.springframework.sessionspring-session-data-redisorg.springframework.bootspring-boot-starter-data-redis

Spring Session 的具体自动配置行为会受到 Spring Boot 版本、配置方式和安全组件影响。

生产项目应根据实际依赖树确认最终生效的 Bean 和过滤器链。

2. 配置 Redis 连接

不要把密码写进仓库。可以在启动环境中设置变量：

export REDIS_HOST=127.0.0.1export REDIS_PORT=6379export REDIS_PASSWORD='change-me'

application.yml 示例：

spring:data:redis:host: ${ REDIS_HOST:127.0.0.1}port: ${ REDIS_PORT:6379}password: ${ REDIS_PASSWORD:}session:store-type: redistimeout: 30mredis:namespace: app:sessionserver:servlet:session:cookie:name: APP_SESSIONhttp-only: truesecure: ${ SESSION_COOKIE_SECURE:true}same-site: lax

secure: true 的作用很直接：它会要求浏览器只能通过 HTTPS 发送 Cookie。

也就是说，如果本地还是用明文 HTTP 做调试，这个选项通常得先临时关掉；但要特别注意，本地调试时的这套配置，不能原封不动带到生产环境里。

至于 SameSite 怎么选，关键要看业务里有没有跨站跳转、统一登录，或者嵌入式页面这些场景。

不能因为“目前还能登录”，就草率地认定配置已经没问题。

3. 登录时创建 Session

控制器可以在认证成功后写入最小必要信息：

@RestController@RequestMapping("/auth")public class AuthController { private final UserService userService;public AuthController(UserService userService) { this.userService = userService;}@PostMapping("/login")public Map login(@RequestBody LoginRequest request,HttpServletRequest httpRequest) { User user = userService.authenticate(request.username(), request.password());if (user == null) { throw new ResponseStatusException(HttpStatus.UNAUTHORIZED, "invalid credentials");}HttpSession session = httpRequest.getSession(true);session.setAttribute("USER_ID", user.id());session.setAttribute("LOGIN_AT", Instant.now().toString());return Map.of("authenticated", true);}@PostMapping("/logout")public Map logout(HttpServletRequest request) { HttpSession session = request.getSession(false);if (session != null) { session.invalidate();}return Map.of("authenticated", false);}}

示例中的密码校验应交给成熟的密码哈希方案完成，不能自行使用简单摘要或明文比较。

登录成功后只保存用户标识，不建议把频繁变化的权限全集长期复制到 Session 中，否则权限变更后可能出现旧状态继续生效的问题。

4. 在接口中校验身份

可以通过拦截器、过滤器或 Spring Security 统一校验，而不是在每个控制器中重复编写。

一个简化的拦截器示例：

@Componentpublic class LoginInterceptor implements HandlerInterceptor { private static final Set PUBLIC_PATHS = Set.of("/auth/login", "/health");@Overridepublic boolean preHandle(HttpServletRequest request,HttpServletResponse response,Object handler) throws IOException { if (PUBLIC_PATHS.contains(request.getRequestURI())) { return true;}HttpSession session = request.getSession(false);Object userId = session == null  null : session.getAttribute("USER_ID");if (userId == null) { response.sendError(HttpServletResponse.SC_UNAUTHORIZED);return false;}return true;}}

实际项目还应区分“未登录”和“无权限”。

• 前者通常返回 401。
• 后者通常返回 403。

健康检查、静态资源和登录接口是否公开，也应按路由明确配置。

安全与一致性

防止会话固定攻击

用户登录前后不应继续沿用同一个 Session 标识。

认证成功后应更换 Session 标识，或使用框架提供的会话迁移能力。

否则，攻击者若能提前诱导用户使用一个已知标识，可能在用户登录后复用该标识。

防止 Cookie 被脚本读取

登录 Cookie 通常应启用 HttpOnly，降低页面脚本读取会话标识的风险。

它不能防止跨站请求伪造，因此仍需结合 SameSite、CSRF Token 或其他请求来源校验。

对于修改数据的接口，不能只依赖浏览器默认行为。

处理 Redis 故障

Session 读取失败时，应用不能简单把所有请求当成“未登录”并无限重试。

合理策略需要根据业务决定。

• 登录、支付、权限变更等接口通常应快速失败并记录告警。
• 部分只读页面可以显示降级内容。

重试必须设置次数和超时上限，否则会把 Redis 故障放大为线程池耗尽。

控制过期时间与续期

Session 过期时间应与安全要求和用户体验共同决定。

• 固定过期时间便于控制风险。
• 滑动过期可以减少活跃用户频繁重新登录，但会延长会话存活窗口。

对后台管理系统，还可以增加绝对过期时间，避免长期活跃操作无限续期。

多实例部署检查清单

• 所有实例使用同一个 Session 存储命名空间。
• 实例之间的 Cookie 域名、路径和安全属性保持一致。
• Redis 连接超时、连接池和故障策略经过明确配置。
• Session 内容可序列化，避免写入不可兼容的临时对象。
• 发布时评估类名或序列化结构变化对旧会话的影响。
• 监控活跃会话数量、Redis 延迟、错误率和过期删除情况。

常见问题

为什么浏览器没有保存 Cookie？

先检查响应是否真的包含 Set-Cookie，再检查域名、路径、Secure、SameSite 和过期时间。

开发环境使用 HTTP 而 Cookie 设置了 Secure，是常见原因。

跨域请求还需要同时检查前端是否发送凭据，以及服务端 CORS 是否允许凭据。

为什么登录后偶尔变成未登录？

可能是请求落到了不同实例，而 Session 没有共享；也可能是 Redis 键过期、网络超时、Cookie 域配置不一致，或应用在登录后更换标识时客户端没有正确接收新 Cookie。

应结合请求链路、实例标识、Session 标识哈希和 Redis 日志定位，不要只看前端页面现象。

是否应该把用户对象直接存入 Session？

通常不建议。

完整对象可能过大，序列化结构也容易随版本变化。

更稳妥的方式是保存用户 ID、租户 ID 和必要的认证上下文，当前请求需要展示的资料再从缓存或数据库读取，并为权限变更设计缓存失效机制。

负载均衡的会话粘滞能替代 Redis 吗？

在满足特定部署条件时，粘滞会话可以减少跨实例读取，但它不能解决实例重启、故障转移和扩缩容后的状态迁移问题。

它更像流量路由策略，而不是可靠的共享状态存储。

是否采用，应根据可用性目标和基础设施能力评估。

总结

Cookie 负责让客户端在后续请求中携带会话标识，Session 负责在服务端保存与该标识对应的状态。

单机内存实现简单，却不适合需要重启恢复和多实例访问的场景；Redis 等共享存储可以解决可见性问题，但必须同时处理超时、序列化、过期、故障降级和容量管理。

落地时应坚持几个原则：

• Cookie 只放不可预测的标识并启用合适的安全属性。
• 登录成功后更新会话标识。
• 服务端统一处理认证与授权。
• Session 内容保持精简。
• 分布式部署前验证共享存储和故障行为。

这样才能把“记住用户”从浏览器技巧，落实为可审计、可运维的认证状态管理机制。