什么时候需要 Session

Session 的核心价值很简单：让多次请求之间共享一点状态。
在 Feat Cloud 里，它的 API 不复杂，真正需要思考的是“我是不是该在这里使用 Session”。

最常见的用法

最简单的方式，是在 Controller 方法里直接注入 Session：

@Controller
public class UserController {

    @RequestMapping("/visit")
    public String visitCount(Session session) {
        String count = session.get("visitCount");
        int visits = (count == null ? 0 : Integer.parseInt(count)) + 1;
        session.put("visitCount", String.valueOf(visits));
        return "Visit count: " + visits;
    }
}

这种写法很适合：

• 演示访问计数
• 保存简单登录状态
• 做轻量级用户上下文

它适合保存什么

适合保存：

• 用户 ID
• 用户名
• 简单角色信息
• 访问计数或短期状态

不适合保存：

• 大对象
• 敏感明文数据
• 需要长期可靠持久化的业务信息

本地 Session 和 Redis Session 怎么理解

本地 Session

适合：

• 单机部署
• 开发环境
• 简单应用

Redis Session

适合：

• 多实例部署
• 需要跨节点共享会话
• 明确依赖集中式 Session 存储

换句话说，选择哪种模式，决定因素通常不是业务代码，而是你的部署形态。

常用操作

session.put("username", "john");
String username = session.get("username");
session.setTimeout(1800);
String sessionId = session.getSessionId();
session.invalidate();

这组 API 本身并不复杂，复杂的是你如何管理状态边界。

一个更重要的问题：你真的需要 Session 吗

如果你的应用已经开始走向下面这些方向：

• 前后端分离
• Token 认证
• 多端登录
• 更复杂的权限和身份体系

那你通常应该更谨慎地使用 Session，而不是默认把所有状态都塞进去。

所以这页真正的建议不是“Session 很强大”，而是：

在它足够简单时用它，一旦应用边界复杂起来，就重新审视它是否还是最合适的状态模型。

常见问题

Session 为什么会丢

最常见的原因是：

• 你以为自己还是单机，实际上已经多实例部署
• 客户端没有正确带回 Cookie
• Session 超时设置太短

为什么不建议往 Session 里塞大对象

因为它会直接扩大状态体积，也会让问题更难追踪。
Session 更适合保存“索引型信息”，而不是完整业务对象。

下一步

• 如果你还在写控制器，先回到 Controller 开发实践
• 如果你开始考虑部署形态，再去看 交付一个 Feat Cloud 应用