revel 的 session 是请求级临时存储，无法跨请求异步修改；需通过时间戳标记+请求时校验的方式实现“过期自动清理”，而非依赖 time.afterfunc 异步删除。
在 Revel 框架中，Session 并非服务端持久化会话（如基于 Redis 或内存 map 的全局 session store），而是基于加密签名 Cookie 的客户端存储机制。每次 HTTP 请求到达时，Revel 会解析客户端 Cookie 中的 session 数据，生成一个全新的、只读（或仅限当前请求生命周期内可写）的 c.Session 实例；响应返回后，该实例即被丢弃，其所有变更（包括 delete() 调用）仅影响本次响应所序列化的 Cookie 值——不会作用于后续请求的 session 状态。
因此，以下代码是无效的：
time.AfterFunc(time.Minute, func() {
delete(this.Session, CSecurityCode) // ❌ 错误：this.Session 已失效，此操作无实际效果
})this.Session 是上一个请求上下文中的快照，AfterFunc 在后台 goroutine 中执行时，该 session 实例早已被 GC 回收，且无法触达客户端或影响下一次请求的 session 解析。
✅ 正确做法：将过期逻辑移至每次请求入口处，结合时间戳实现逻辑过期控制：
- 写入时记录时间戳：在设置验证码时，同时写入当前时间（Unix 时间戳）；
- 读取前校验时效：每次需要使用 CSecurityCode 前，先检查 lastSeen 是否超时（如 ≥ 60 秒）；
- 超时则逻辑清除：若已过期，跳过使用并可选择主动从 session 中移除（delete(c.Session, CSecurityCode) + delete(c.Session, "lastSeen")），确保后续请求不再误用。
示例实现：
const (
CSecurityCode = "captcha_code"
SessionTTL = 60 // seconds
)
// 设置验证码（含时间戳）
func (c App) SetCaptcha(code string) {
c.Session[CSecurityCode] = code
c.Session["lastSeen"] = fmt.Sprintf("%d", time.Now().Unix()) // 存字符串便于序列化
c.Session.Save() // 必须显式 Save 才会写入响应 Cookie
}
// 安全获取验证码（自动过期检查）
func (c App) GetCaptcha() (string, bool) {
lastSeenStr := c.Session["lastSeen"]
if lastSeenStr == "" {
return "", false
}
lastSeen, err := strconv.ParseInt(lastSeenStr, 10, 64)
if err != nil || time.Now().Unix()-lastSeen > SessionTTL {
// 过期：清除验证码及时间戳
delete(c.Session, CSecurityCode)
delete(c.Session, "lastSeen")
c.Session.Save()
return "", false
}
return c.Session[CSecurityCode], true
}⚠️ 注意事项：
- Revel 默认 session 过期由 Cookie 的 Expires/Max-Age 控制（可通过 revel.SessionExpire 配置），但这是浏览器端强制失效，无法替代业务逻辑层的精确时效判断；
- c.Session.Save() 必须显式调用才能将变更提交到响应 Cookie，否则所有写操作（包括 delete）均不生效；
- 不要尝试在 goroutine、中间件初始化或控制器方法外修改 c.Session，它严格绑定于单次请求生命周期；
- 如需更严格的会话管理（如服务端强制踢出、实时失效），应引入外部 session store（如 Redis），并自行实现 SessionController 替换默认行为。
总结：Revel 的 session 设计强调无状态与轻量，开发者需将“时效性”逻辑下沉至请求处理流程中，以时间戳驱动条件判断，而非依赖异步清理——这既是约束，也是保障高并发下 session 一致性的关键设计哲学。
