Beego Session需同时满足开启、存储配置、过期控制三条件才生效：必须设sessionon=true启用，SessionGCMaxLifetime控制服务端存活时长（单位秒），SessionCookieLifeTime设定浏览器Cookie有效期。
Beego 的 Session 不是“设了就生效”，必须同时满足开启、存储配置、过期控制三个条件，缺一不可。
sessionon = true 是前提，否则其他配置全被忽略
Beego 默认关闭 Session，sessionon = true 必须显式启用，否则 SetSession、GetSession 都不会真正写入或读取任何数据，也不会报错——只会静默失败。
- 可在
conf/app.conf对应环境段（如[prod]）中添加：sessionon = true - 也可在
main.go中代码启用：beego.BConfig.WebConfig.Session.SessionOn = true，但需放在beego.Run()之前 - 若用代码方式设置，注意 Beego v2+ 中部分配置（如
SessionGCMaxLifetime）不会热重载，修改后必须重启进程
SessionGCMaxLifetime 控制服务端实际存活时长
SessionGCMaxLifetime 是服务端 Session 生效的核心参数，单位为秒，表示“最后一次访问后最多保留多久”。它不是创建后固定过期，而是每次 GetSession 或 SetSession 都会刷新倒计时。
- 例如设为
SessionGCMaxLifetime = 1800，用户静默 30 分钟后再发请求，该 Session 可能已被 GC 清理（取决于 GC 执行时机） - 该值只对
memory和file等 provider 起主控作用；若用redis，则优先使用sessionproviderconfig末尾的 TTL（如"127.0.0.1:6379,0,30"中的30） - 必须是整数，不能写
30m或1.5h；写错格式会导致配置解析失败，降级为默认 3600 秒
SessionCookieLifeTime 决定浏览器 Cookie 是否还在
即使服务端 Session 还活着，如果浏览器里没有 gosessionid（或自定义 sessionname）这个 Cookie，请求就无法关联到对应 Session。而 Cookie 默认是会话级（关浏览器即丢），必须靠 SessionCookieLifeTime 显式延长。
A powerful memory management system powered by ReMe that provides persistent cross-session memory, automatic user preference application, and intelligent context compression for OpenClaw.
下载
由 ReMe 驱动的记忆管理系统，支持跨会话记忆持久化、自动应用用户偏好以及智能上下文压缩...
- 在
app.conf中添加：SessionCookieLifeTime = 3600，它会写入响应头Set-Cookie: gosessionid=xxx; Max-Age=3600 - 该值和
SessionGCMaxLifetime无强制相等关系，但建议设为相同或略大，避免 Cookie 先失效导致“Session 还在，却拿不到” - 若用
cookie类型 provider（不推荐用于敏感数据），此配置还影响加密 Cookie 的签名有效期
Provider 类型直接影响 GC 行为和持久性
不同 sessionprovider 对过期逻辑处理差异极大，选错类型会导致“明明配了却像没配”：
-
memory：依赖 Beego 启动的 goroutine 定时 GC，重启即丢失；适合开发调试 -
file：GC 不敏感，可能长期残留过期 session 文件（尤其在低频访问场景），需手动清理或改用外部存储 -
redis：TTL 由 Redis 自身管理，更可靠；但需确保sessionproviderconfig格式正确，末尾数字是 TTL 秒数 -
cookie：Session 数据直接加密存 Cookie，无服务端存储，但受 4KB 限制且不安全，仅适合公开、非敏感信息
最容易被忽略的是：用了 redis 却只配了 SessionGCMaxLifetime，没在 sessionproviderconfig 里指定 TTL，结果 Redis key 永不过期。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
