面经策

Spring 中的 @SessionAttribute 注解的作用是什么？ ​

  • 标签：后端、Spring

🏛 业务架构师 ​

@SessionAttribute 的作用是把 HTTP Session 中的属性绑定到方法参数上（注意与 @SessionAttributes 区分：后者标在 Controller 类上，声明哪些模型属性暂存到 Session，用于经典的多步表单向导场景）：

java
@GetMapping("/checkout")
public String checkout(@SessionAttribute("loginUser") User user) { ... }

架构师视角，我对它的态度是**"理解它，但新架构不推荐使用"**，理由是业务演进的大势：

  1. 有状态服务的代价：Session 存在容器内存里，服务不能随意扩缩容——两台实例各自的 Session 不互通，负载均衡需要粘性会话（session affinity），弹性伸缩能力直接被锁死，这在 K8s 动态调度的环境里是致命约束；
  2. 主流替代方案：登录态外置——JWT 无状态令牌，或 Session 集中存 Redis（Spring Session 一行依赖完成，应用无感），服务本身保持无状态。后者是渐进式改造的首选：老代码用 @SessionAttribute 读会话，接入 Spring Session 后底层自动切到 Redis，零代码改动获得多实例部署能力——这种"不动业务代码的基础设施替换"正是架构改造最希望的低风险路径；
  3. 遗留维护场景（内部管理系统、老门户）仍会遇到它，理解绑定机制与超时语义即可。

一句话：会话属性绑定是历史能力，架构上把状态赶出进程（Redis/JWT）才是现代答案。

🏗 系统架构师 ​

作用：把已存在的 HTTP session 属性绑定到方法参数（以读为主，可设 required=false），与向 session 写入的 @SessionAttributes/HttpSession 区分。

从这里引出的架构问题才是重点：session 状态是水平扩展的天敌。

  • 有状态实例的代价：负载均衡必须粘性路由（均衡性差、故障转移丢会话），或者会话复制（广播开销随实例数恶化）；
  • 我的标准解法是去状态化：会话数据外置 Redis 加 Spring Session（@EnableRedisHttpSession——session id 走 cookie，数据走 Redis），实例变回无差别副本；再进一步，认证态改 token/JWT 无会话化，服务端只做校验；
  • 容量估算：100 万活会话乘 2KB 约 2GB，Redis 单实例可承载，但要设计 TTL、淘汰策略与命中率——会话存储的可用性等于用户可用性，它的持久化与容灾等级要高于普通缓存，预算要按这个标准给。

💻 全栈开发专家 ​

@SessionAttribute 用来读取已存在于 session 里的属性（注意：不是写入）：

java
@GetMapping("/me")
public UserVO me(@SessionAttribute("loginUser") User user) { ... }

session 里没有该属性时抛 HttpSessionRequiredException。区分三个易混的东西：

  • @SessionAttribute：方法参数上，读已有 session 属性
  • @SessionAttributes：类上，声明哪些 Model 属性暂存 session（配合 @ModelAttribute，传统向导式页面用）
  • 写 session：直接 HttpSession#setAttribute 或 Model + @SessionAttributes

2026 现实：分布式多实例下原生 session 早不是默认选项，标准解法是 Spring Session：引 spring-session-data-redis 依赖 + @EnableRedisHttpSession，session 透明落 Redis，代码一行不改。更主流的做法是彻底无 session：token 放 Redis/网关统一鉴权，@SessionAttribute 只在历史项目里还能见到。答题把这层演进讲出来，说明踩过分布式的坑，比背注解定义值钱。