beego 默认 memory session 不支持多实例部署，因数据仅存于单进程内存，负载均衡导致请求分发到不同节点时无法找到 session；必须改用 redis 等分布式后端，配置 sessionprovider="redis" 并统一 sessiongcmaxlifetime。
Beego 默认的 memory Session 无法用于多实例部署，必须切换为支持分布式共享的后端，否则用户登录后刷新就掉线。
为什么 memory Session 在集群下会失效
memory 提供者把 session 数据存在单个进程内存里，没有跨进程通信机制。当负载均衡把同一个用户的后续请求分发到另一台机器时，GlobalSessions 找不到对应的 beegosessionID，返回空 session —— 表现为“刚登录完就登出”或 GetSession("username") 总是 nil。
这不是代码 bug，是存储层设计限制。哪怕你用了 SessionRegenerateID() 或反复调用 StartSession()，也解决不了数据不共享的问题。
- 所有节点必须读写同一份 session 数据源
- session ID（即 Cookie 中的
beegosessionID）仍由客户端携带，服务端只负责按 ID 查数据 - GC 清理逻辑（
GlobalSessions.GC()）需在所有节点上运行，但清理动作本身是安全的：重复清理同一条过期记录无副作用
Redis 是最稳妥的分布式 Session 方案
Redis 响应快、支持 TTL 自动过期、天然支持多客户端并发读写，且 beego 内置适配完整。配置只需两步：
- 在
conf/app.conf中设置：sessionon = true sessionprovider = "redis" sessionproviderconfig = "127.0.0.1:6379,0,beego_session"
-
sessionproviderconfig格式为"addr,db,password,prefix"，其中prefix可选，用于隔离不同环境的 session key（如dev_session/prod_session） - 确保 Redis 实例可被所有应用节点访问；若用密码，必须 URL 编码（如
pass%40word）
不需要改任何 controller 代码 —— SetSession()、GetSession()、DelSession() 的行为完全不变，底层自动走 Redis 读写。
file 提供者不适合生产环境的分布式场景
虽然 sessionprovider = "file" 看似能“持久化”，但它依赖本地文件系统，多个进程同时写入同一目录极易触发锁竞争、文件覆盖或 panic（尤其是高并发下 os.Rename 失败）。官方文档也明确标注 file 仅用于开发调试。
常见错误现象包括：
- 部分请求返回
http: multiple response.WriteHeader calls - 日志中频繁出现
open ./tmp/xxx: no such file or directory - 用户 A 登录后，用户 B 的 session 数据意外变成 A 的
即使挂载 NFS 或 CephFS，也无法规避 inode 不一致与缓存延迟问题，不推荐任何形式的共享文件系统方案。
Session GC 和过期时间必须全局对齐
SessionGCMaxLifetime 控制的是 session 最大空闲存活时间（单位秒），它直接影响 Redis 中 key 的 TTL。如果不同节点配置值不一致，会导致：
- 节点 A 设置了
3600，节点 B 设置了7200→ 节点 B 会读到已被 A 清理的 session - GC goroutine 频率不一致，可能堆积大量过期 key 占用内存
务必统一通过配置文件设置：
sessiongcmaxlifetime = 3600，不要在代码里用
beego.BConfig.WebConfig.Session.SessionGCMaxLifetime 覆盖 —— 容易漏改某台机器的启动脚本。
Redis 本身会自动清理过期 key，但 beego 的 GC 仍需运行：它负责扫描并主动删除已过期的 session 记录（尤其当 key 被手动删掉但内存索引未清除时）。所以 go GlobalSessions.GC() 这行不能省。
