Beego中Session过期时间由SessionGCMaxLifetime控制，表示最后一次访问后最大存活秒数，每次读写均刷新倒计时；需配合SessionCookieLifeTime设置Cookie有效期，且必须开启sessionon=true才生效。
Beego 中 Session 过期时间由 SessionGCMaxLifetime 控制
Beego 默认不使用浏览器 Cookie 的 Expires 或 Max-Age 属性来控制过期，而是靠服务端 GC（垃圾回收）机制主动清理过期 Session。真正起作用的是配置项 SessionGCMaxLifetime，它表示 Session 在内存/存储中“自最后一次访问起”的最大存活秒数。
注意：这不是“创建后固定时长”，而是“最后操作后多久失效”——每次读写 Session 都会刷新这个倒计时。
-
SessionGCMaxLifetime = 3600表示用户静默一小时后，下次请求可能触发 Session 清除（取决于 GC 执行时机） - 该值必须是整数秒，单位不能是毫秒或分钟
- 修改后需重启 Beego 应用才生效（热重载不触发 session 配置重载）
如何在 app.conf 中正确设置
在 conf/app.conf 的对应运行模式段（如 [dev] 或 [prod]）下添加：
sessionon = true sessionprovider = "memory" sessionname = "gosessionid" SessionGCMaxLifetime = 1800
关键点：
- 必须确保
sessionon = true已开启，否则其他配置无效 -
sessionprovider类型影响 GC 行为：内存型（memory）依赖定时 GC；Redis/Memcache 等外部 provider 通常靠自身 TTL 实现，此时SessionGCMaxLifetime仅用于 fallback 或初始化 TTL 值 - 若用
redisprovider，还需额外设置sessionproviderconfig = "127.0.0.1:6379,0,30"，末尾的30是 Redis key 的默认 TTL 秒数（优先级高于SessionGCMaxLifetime）
为什么设置了没生效？常见原因
最常踩的坑不是配错参数名，而是混淆了「客户端 Cookie 过期」和「服务端 Session 过期」两个维度：
- 浏览器 Cookie 本身也有过期时间，默认是会话级（关闭浏览器即失效），即使服务端 Session 还活着，Cookie 消失后也无法再关联
- 要延长 Cookie 存活，需额外配置
SessionCookieLifeTime = 3600（单位秒），它控制 Set-Cookie 响应头中的Max-Age - 如果只设了
SessionGCMaxLifetime但没设SessionCookieLifeTime，用户关掉浏览器再打开，gosessionidCookie 就没了，自然拿不到 Session - Beego v2+ 版本中，部分 provider（如
file）对 GC 不敏感，可能长期残留文件，建议搭配sessionproviderconfig = "./tmp"和定期清理脚本
验证是否生效的简单方法
不要依赖日志或文档猜测，直接观测行为：
- 启动应用后，用 curl 获取一次 Session：
curl -I http://localhost:8080/，记下响应头里的Set-Cookie: gosessionid=xxx; Path=/; Max-Age=3600—— 这个Max-Age来自SessionCookieLifeTime - 检查 Beego 启动日志是否有
[INFO] Session gc lifetime: 1800，确认配置被加载 - 手动写个测试 handler，调用
this.StartSession()后打印this.CruSession.Get("test")和this.CruSession.SessionID()，再等待超时时间过去，再次请求看是否返回 nil
真正难调试的是多节点部署时的 Session 共享问题——此时单靠 SessionGCMaxLifetime 不够，必须统一 provider（如 Redis）并确保所有实例配置完全一致，否则 GC 时间不同步会导致“有时有效、有时 401”。
