Beego 默认 memory Session 不支持跨实例共享，必须切换为 Redis 并正确配置 driver、连接串、TTL 和 Cookie 域；常见错误包括未导入 Redis 驱动、sessionproviderconfig 格式错误、TTL 不一致、Cookie domain 设置不当及登出未用 DestroySession。
Beego 默认的 memory Session 存储无法跨实例共享，必须显式切换为 redis（或其他分布式后端），否则负载均衡下用户反复登录、数据不一致是必然结果。
为什么改了配置但 session 还是不共享
常见错误是只改了 sessionprovider = "redis"，却没配 sessionproviderconfig 或配错格式；更隐蔽的是：Beego v2 的 Redis 驱动依赖 github.com/gomodule/redigo/redis，但默认不自动加载——若没在代码里显式 import 对应驱动包，运行时会静默 fallback 到 memory，SetSession 看似成功，实则写进了本地内存。
- 检查日志是否出现
session provider redis not registered类警告 -
sessionproviderconfig必须是完整连接字符串，例如："127.0.0.1:6379,0,beego_session"（地址,数据库ID,密码，密码为空时逗号不能省） - Beego v2 中需确保已执行
import _ "github.com/beego/beego/v2/server/web/session/redis"（注意下划线导入）
Redis 连接与超时必须对齐
Beego 的 sessiongcmaxlifetime 控制服务端清理逻辑，但 Redis 里的 key TTL 是另一回事。若两者不一致，会出现“用户还在用，Redis 已删 key”或“key 永不过期导致内存泄漏”。
- 设
sessiongcmaxlifetime = 3600（1小时）的同时，sessionproviderconfig末尾要加,3600表示 TTL，完整值如："127.0.0.1:6379,0,,3600" - Redis 连接池参数不可忽略：
maxidle和maxactive建议设为并发请求数的 2–3 倍，否则高流量下GetSession可能阻塞甚至返回 nil - 避免在
GetSession后直接做耗时操作（如查 DB），Session 锁未释放会导致后续同 ID 请求排队
多子域名下 Cookie Domain 配置失效
Session ID 能跨服务器共享，不代表 Cookie 能被所有子域名读取。这是纯前端 HTTP 协议限制，和 Redis 无关，但常被归咎于后端配置。
- Beego 中必须显式设置
sessiondomain = ".example.com"（开头带点），写成example.com或app.example.com都无效 - 开发环境用
localhost时，浏览器禁止设二级域名 Cookie，临时方案是绑 hosts + 用127.0.0.1.xip.io类域名 - 若前端 AJAX 跨域请求，后端需响应
Access-Control-Allow-Credentials: true，且 JS 请求中必须带credentials: "include"
最易被忽略的一点：Beego 的 DelSession 和 DestroySession 在 Redis 下行为不同——前者只删 key，后者还会清空整个 session 数据结构并重置 ID；登出逻辑若只调 DelSession，旧 session ID 对应的 Redis key 可能残留，下次用同一 ID 访问仍能读到残留值。
