Revel 的 Session 是加密签名 Cookie，需显式调用 Save() 才生效；值必须为字符串、Key 不含冒号；生命周期仅限当前请求，禁止在 goroutine 中使用。
Revel 默认用加密签名 Cookie 存储 Session，不是服务端 session store；只要不超 4KB、数据能转成字符串，就能直接写 c.Session["key"] = "value"，响应时自动序列化进 Set-Cookie。
Session 写入必须调用 Save() 才生效
Revel 的 c.Session 是请求级快照，修改后不会自动持久化到响应 Cookie 中。漏掉 Save() 是最常见失效原因。
-
c.Session["user_id"] = "123"只是内存赋值，不触发写 Cookie - 必须显式调用
c.Session.Save()，否则客户端收不到更新后的 session - 若在中间件或过滤器中修改 session，同样需要
Save()，且确保它在 response 写出前执行
避免在 goroutine 中操作 c.Session
Session 实例生命周期仅限当前 HTTP 请求上下文，异步任务（如 time.AfterFunc）里访问它必然失败。
-
time.AfterFunc(30*time.Second, func() { delete(c.Session, "token") })❌ 无效：此时c.Session已被回收 - 所有时效控制逻辑（如验证码过期）必须放在每次请求入口处校验，结合时间戳字段（如
"lastSeen"）做逻辑清理 - 真正“删除”只需
delete(c.Session, "key")+c.Session.Save()，无须后台清理
注意 Key 命名与数据类型限制
Revel 的 Session 底层是 map[string]string，所有值都会被强制转为字符串，Key 也不能含冒号。
- 不能用结构体或数字直接赋值：
c.Session["count"] = 42会 panic；得写c.Session["count"] = "42" - Key 中出现
:（如"user:123"）会导致解析失败，建议用下划线代替 - 敏感信息（如 token）虽经签名防篡改，但未加密——用户可 base64 解码看到明文，勿存密码、密钥等
真正要注意的不是“怎么存”，而是“怎么让它在下个请求里还可用”：确保没跨请求误用实例、没漏 Save()、没把二进制或嵌套结构硬塞进去——这些地方一错，session 就静默丢数据，调试时很难定位。
