beego默认不启用session，必须显式配置：代码中设beego.bconfig.webconfig.session.sessionon = true或配置文件写sessionon = true，否则getsession总返回nil。
Session 开启必须显式配置，否则 GetSession 总是返回 nil
Beego 默认不启用 Session 模块，哪怕你调用了 c.SetSession 或 c.GetSession，也不会报错，但所有操作都静默失效——GetSession 返回 nil，DelSession 无效果。这是最常被忽略的“假成功”陷阱。
必须二选一启用：
- 代码方式：在
main.go中beego.Run()调用前加beego.BConfig.WebConfig.Session.SessionOn = true - 配置文件方式：在
conf/app.conf中写sessionon = true（注意不是session_on或其他变体）
二者不可共存；若同时设置，以代码为准。配置文件方式更利于多环境切换，但本地开发时容易漏改 app.conf 导致调试失败。
Session ID 依赖 Cookie，禁用 Cookie 后 Session 失效是默认行为
Beego 的 Session 机制默认把 Session ID 存在客户端 Cookie 中，键名为 beegosessionID（可配置）。这意味着：
- 浏览器禁用 Cookie →
SetSession仍能执行，但后续请求无法携带 ID →GetSession拿不到任何值 - 用户手动清除 Cookie → 相当于换了一个新会话，旧 Session 数据仍在服务端（取决于引擎），但无法再关联
- 跨域请求（如前端用 Vue CLI 代理到 Beego 后端）若未设
withCredentials: true+ 后端响应头Access-Control-Allow-Credentials: true，Cookie 不会发送，Session 断连
不要试图靠 “前端传 session_id 参数” 来绕过——Beego 不支持 URL 传递 Session ID 的 fallback 模式（不像 PHP 的 session.use_trans_sid），强行拼接只会让服务端生成新 Session。
Session 引擎选 memory 还是 redis？看部署规模和数据持久性需求
memory 是 Beego 默认引擎，所有 Session 数据存在进程内存里。它快，但有硬伤：
- 单机多实例（比如用 supervisor 启了 4 个 beego 进程）→ 用户请求打到不同进程 → Session 不共享 → 登录态随机丢失
- 进程重启 → 全部 Session 清空 → 用户强制登出
生产环境推荐 redis 引擎，需额外配置：
sessionon = true sessionprovider = redis sessionproviderconfig = "127.0.0.1:6379,0,abc123"
其中第三段是 addr,db,password，密码为空时写 ""（不能省略）。注意：redis 引擎下，SetSession 写入的是序列化后的 interface{}，不支持函数、channel 等无法序列化的类型——传 struct 或 map[string]interface{} 才安全。
Cookie 本身不加密，敏感信息绝不能直接塞进 SetCookie
c.Ctx.SetCookie("auth_token", token, 3600, "/") 这种写法等于把令牌明文暴露给浏览器，攻击者打开开发者工具就能复制使用。Beego 提供了加密 Cookie 支持，但必须主动启用：
- 在
conf/app.conf加cookieencrypt = true和cookiekey = "your-32-byte-secret-key-here" - 密钥长度必须为 16 或 32 字节（对应 AES-128 / AES-256），用
openssl rand -hex 32生成最稳妥 - 启用后，
c.Ctx.SetCookie写入的值会被自动加密，c.Ctx.GetCookie返回解密后内容
但要注意：加密只防窃取，不防篡改。如果业务逻辑依赖 Cookie 值做权限判断（比如 role=admin），仍需服务端校验——攻击者即使解不开密文，也能重放旧 Cookie 维持会话。真正该放 Session 的东西（如用户 ID、角色）别贪方便扔进 Cookie。
