Session管理器必须手动初始化并显式调用sess.Start(ctx)，否则每次请求生成新ID；Cookie名需自定义、Expires应设为24*time.Hour、HttpOnly和Secure必须开启；存取数据须严格类型匹配，Redis部署时必须配置Database和Prefix。
Session 管理器必须手动初始化，不能靠中间件自动挂载
Iris 的 session 不是开箱即用的全局中间件，sessions.New 只返回一个配置好的管理器实例，但不会自动注入请求生命周期。常见错误是只调了 sessions.New 却没在 handler 里调 sess.Start(ctx)，结果每次请求都生成新 session ID，数据根本存不住。
正确做法是：先创建管理器，再在需要 session 的路由 handler 中显式启动：
sess := sessions.New(sessions.Config{
Cookie: "mysessionid",
Expires: 24 * time.Hour,
HttpOnly: true,
CookieSecureTLS: true, // 生产环境 HTTPS 必开
AllowReclaim: true, // 允许用户清 cookie 后续上旧 session（按需）
})
<p>app.Get("/login", func(ctx iris.Context) {
session := sess.Start(ctx) // ← 关键！必须调这个
session.SetString("user", "alice")
ctx.WriteString("logged in")
})
-
Cookie字段必须自定义，别用默认值"irissessionid"，否则多服务共存时易冲突 -
Expires设为0表示“浏览器关闭即失效”，生产环境基本不用；建议显式设为24 * time.Hour或更短 -
HttpOnly: true和CookieSecureTLS: true是安全底线，漏掉可能被 XSS 窃取 session ID
存取数据必须严格匹配类型，否则 panic
Iris 的 Session 对象不支持泛型或自动类型转换，Set 和 Get 方法是类型专用的。比如存了 int64，用 GetInt() 会直接 panic，因为底层不是 int 而是 int64。
推荐写法：
session.SetInt64("score", 95)
score := session.GetInt64("score") // ✅ 安全
<p>session.SetString("name", "bob")
name := session.GetString("name") // ✅</p><p>session.SetBoolean("active", true)
isActive := session.GetBoolean("active") // ✅</p><p>// 存结构体？先 json.Marshal 再 SetBytes
data := map[string]interface{}{"role": "admin", "level": 3}
b, _ := json.Marshal(data)
session.SetBytes("profile", b)</p><p>// 读的时候反向操作
if b := session.GetBytes("profile"); len(b) > 0 {
var profile map[string]interface{}
json.Unmarshal(b, &profile)
}
- 别用
Set("key", value)+Get("key").(type)强转，运行时容易 panic -
GetInt()只兼容 32 位 int，在 64 位系统或跨平台部署时可能截断，一律优先用GetInt64() - 布尔值必须用
SetBoolean/GetBoolean，不要用Set("flag", true)后再强转
上 Redis 后 session 还丢？大概率是 key 配置没对齐
本地跑通、上线就丢 session，90% 是 Redis 配置问题，不是连不上 Redis，而是多个服务写到同一个 DB 或 key 空间里互相覆盖或误删。
必须显式设置这两项：
import "github.com/kataras/iris/v12/sessions/database/redis"
<p>redisDB := redis.New(redis.Config{
Network: "tcp",
Addr: "redis.example.com:6379",
Password: "secret",
Database: 1, // ← 必须指定，不能依赖默认 db 0
Timeout: 3 * time.Second,
})</p><p>sess.UseDatabase(redisDB)
sess.Config.Prefix = "myapp:sess:" // ← 必须加前缀，避免和其他服务混用
-
Database字段缺失会导致所有 Iris 服务都连到 Redis 的 db 0，托管服务（如 AWS ElastiCache、阿里云 Redis）常禁用SELECT命令，不设就失败 -
Prefix不设的话，DestroyAll()会清空整个 DB 的 key，不是只清你自己的 session -
Timeout要用redis.Config{Timeout: ...}，不是裸写3 * time.Second—— 后者会被忽略
ctx.User 不会自动从 Session 恢复，得自己绑定
ctx.User 默认只在当前请求有效，Iris 不会自动从 session 加载用户信息并塞进 ctx.User。如果你登录后想在后续所有 handler 里直接用 ctx.User().GetID()，必须手动做这件事。
通用做法是在全局 middleware 里统一处理：
app.Use(func(ctx iris.Context) {
session := sess.Start(ctx)
if userID := session.GetString("user_id"); userID != "" {
// 假设你有 User 结构体和 FromID 方法
user := User{ID: userID}.FromID()
ctx.SetUser(user) // ← 手动绑定
}
ctx.Next()
})
- 只存 ID 到 session，不要存整个用户对象（序列化开销大、更新不一致）
- 每次请求都查一次 DB 或缓存加载用户，比反复序列化/反序列化更可控
- 如果用了
AllowReclaim: true，要注意 session ID 复用时user_id是否仍合法，建议加一层校验
复杂点在于 session 生命周期、Redis 配置、类型安全这三块是耦合的——改一个地方，另外两个很可能跟着出问题。尤其是 Prefix 和 Database，上线前必须和运维确认 Redis 实例的实际 DB 分配和 key 管理策略。
