HTTP 协议本身是无状态的。客户端发送一个请求，服务器处理并返回响应；下一次请求到来时，服务器不会天然知道它是否来自同一个用户。这个特性简化了协议设计，却给登录、权限、购物车和多步表单带来了问题。
例如，用户先提交登录表单，服务器验证成功。随后用户访问订单页面，订单接口必须知道当前请求对应哪个账号。如果每次请求都重新提交账号和密码，既不方便，也会扩大敏感信息暴露面。因此，应用需要一种机制，把“浏览器中的请求”与“服务器端保存的用户状态”关联起来。
Cookie 和 Session 经常一起出现，但它们解决的不是同一层问题：Cookie 是客户端保存并随请求发送的一小段数据；Session 通常是服务器端保存的状态记录。理解两者的边界，是处理登录失效、跨域、集群部署和安全问题的基础。
工作原理
Cookie 如何参与请求
服务器可以在响应中发送 Set-Cookie：
HTTP/1.1 200 OK
Set-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. 添加依赖
Maven 中加入 Session 与 Redis 支持：
<dependencies>
<dependency>
<groupId>org.springframework.session</groupId>
<artifactId>spring-session-data-redis</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
</dependencies>
Spring Session 的具体自动配置行为会受到 Spring Boot 版本、配置方式和安全组件影响。生产项目应根据实际依赖树确认最终生效的 Bean 和过滤器链。
2. 配置 Redis 连接
不要把密码写进仓库。可以在启动环境中设置变量：
export REDIS_HOST=127.0.0.1
export REDIS_PORT=6379
export 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: redis
timeout: 30m
redis:
namespace: app:session
server:
servlet:
session:
cookie:
name: APP_SESSION
http-only: true
secure: ${
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<String, Object> 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<String, Object> logout(HttpServletRequest request) {
HttpSession session = request.getSession(false);
if (session != null) {
session.invalidate();
}
return Map.of("authenticated", false);
}
}
示例中的密码校验应交给成熟的密码哈希方案完成，不能自行使用简单摘要或明文比较。登录成功后只保存用户标识，不建议把频繁变化的权限全集长期复制到 Session 中，否则权限变更后可能出现旧状态继续生效的问题。
4. 在接口中校验身份
可以通过拦截器、过滤器或 Spring Security 统一校验，而不是在每个控制器中重复编写。一个简化的拦截器示例：
@Component
public class LoginInterceptor implements HandlerInterceptor {
private static final Set<String> PUBLIC_PATHS = Set.of(
"/auth/login", "/health"
);
@Override
public 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 内容保持精简；分布式部署前验证共享存储和故障行为。这样才能把“记住用户”从浏览器技巧，落实为可审计、可运维的认证状态管理机制。
