Beego Session本质是服务端状态维护+客户端Cookie传递SessionID，必须显式开启（配置sessionon=true或代码设SessionOn=true）、选型存储后端（如redis）、协同配置Cookie参数，否则会静默失效。
Beego 的 Session 管理本质是服务端状态维护 + 客户端 Cookie 传递 SessionID，不是开个开关就能用稳的——关键在存储后端选型、生命周期控制、以及和 Cookie 的协同配置。
Session 开启必须配对生效，光改一处会静默失效
Beego 不会自动启用 Session，必须显式开启且确保配置被加载。常见错误是只在 conf/app.conf 里写 sessionon = true，但没确认配置文件路径是否被 beego.LoadAppConfig() 加载；或只在 main.go 里设 beego.BConfig.WebConfig.Session.SessionOn = true，却忘了它必须放在 beego.Run() 之前执行。
-
sessionon = true是唯一有效的配置项名，session_on、enable_session都无效 - 若用
app.conf配置，需确保beego.LoadAppConfig("ini", "conf/app.conf")被调用（默认已做，但自定义加载逻辑时易漏） - Session 存储类型默认是
memory，重启进程即丢失；生产环境务必显式指定sessionprovider = file或sessionprovider = redis
Session ID 依赖 Cookie，禁用 Cookie 就等于禁用 Session
Beego 默认把 SessionID 存在客户端 Cookie 中，键名为 beegosessionID。浏览器禁用 Cookie 后，每次请求都生成新 Session，c.GetSession() 永远取不到旧值——这不是 Beego Bug，是 HTTP 协议层限制。
- 不能靠前端 JS 操作
document.cookie来伪造beegosessionID，Beego 会对该 Cookie 做签名校验 - 如需 URL 传参兜底（不推荐），得手动实现：在登录成功后生成带
sid=xxx的跳转链接，并重写beego.BConfig.WebConfig.Session.SessionName和自定义SessionProvider -
sessiongcmaxlifetime配置单位是秒，默认 3600（1小时），超时后服务端自动清理，但客户端 Cookie 过期时间由sessioncookieLifeTime控制（默认 3600），二者要匹配，否则出现“服务端已删、客户端还在发”现象
GetSession / SetSession / DelSession 的行为边界很明确
这三个方法操作的是当前请求绑定的 Session 实例，不是全局变量。它们不触发立即写入或删除，而是延迟到响应头发出前批量处理。
-
c.SetSession("key", value)的value必须是可序列化类型（string、int、struct等），func或chan会导致 panic -
c.GetSession("key")返回interface{}，需类型断言；若 key 不存在，返回nil，不是空字符串或零值——别用== ""判空，要用== nil或!= nil -
c.DelSession("key")只删除键，不销毁整个 Session；要彻底退出登录，得组合使用c.DelSession("username")+c.DestroySession() - 跨子域名共享 Session？需额外设
sessioncookieDomain = ".example.com"，且主域和子域必须同源
权限校验场景下，Session 常和 Filter 配合，但别在 Prepare() 里硬取
很多开发者把登录校验逻辑塞进 Prepare()，然后直接调 c.GetSession("user_id")，结果在 POST 表单提交或 API 调用时偶尔取不到——因为 Beego 的 Session 初始化发生在 BeginRequest() 阶段，而 Prepare() 执行时机略早于完整解析，尤其在 multipart/form-data 请求中更不稳定。
- 正确做法：在自定义 Filter（如
authFilter）中通过ctx.Input.CruSession获取，它已确保初始化完成 - 不要在 Filter 里调
DelSession，会干扰后续 Controller 的 Session 使用；应只做读取判断，删除动作留给专门的LogoutController - 敏感操作（如修改密码、支付）建议二次验证：从 Session 读出
user_id后，再查一次数据库确认账号状态，避免 Session 被劫持后凭缓存作恶
Session 不是黑盒，它的生命周期、存储位置、传输方式全部可控，但每个环节都有隐含约束。最容易被忽略的是：内存型 Session 在多实例部署时完全不可用，而 Redis 后端又要求提前配置好连接池和超时参数——这些不在 sessionon = true 里体现，却直接决定系统能否上线。
