gin-contrib/sessions 默认不持久化到 redis 是因默认使用内存型 cookie.store，v1.x 版本已移除内置 redis 支持，需手动实现 sessions.store 接口并配合 go-redis/v9 等客户端封装适配器。
为什么 gin-contrib/sessions 默认不持久化到 Redis？
因为它的默认实现是内存存储（cookie.Store），Redis 需要你显式传入一个实现了 sessions.Store 接口的后端。直接用 redis.NewStore 会报错——它返回的是 *redis.Store，但 Gin 中间件只认 sessions.Store，而这个类型在 v0.1.x 和 v1.x 之间有 breaking change。
常见错误现象：cannot use redis.NewStore(...) (value of type *redis.Store) as sessions.Store value in argument to sessions.Sessions
- v0.1.x 版本（旧）：用
github.com/gin-contrib/sessions/redis，导出NewStore - v1.x 版本（新）：统一收归到
github.com/gin-contrib/sessions，Redis 后端需自己包装或换用redisstore包 - 如果你
go get github.com/gin-contrib/sessions拉到的是 v1.2+，就别再找redis.NewStore—— 它不存在了
怎么配通 Redis + Gin Session（v1.x 正确姿势）
必须用社区维护的 github.com/gomodule/redigo/redis 或 github.com/go-redis/redis/v9 自行构造 sessions.Store 实现。官方 gin-contrib/sessions v1.x 不再内置 Redis 支持，这是最容易卡住的点。
推荐用 github.com/go-redis/redis/v9 + 封装适配器，示例关键片段：
立即学习“go语言免费学习笔记（深入）”；
// 用 go-redis/v9 初始化 client
rdb := redis.NewClient(&redis.Options{
Addr: "localhost:6379",
})
// 实现 sessions.Codecs（用于加解密 session 数据）
var store = &redisStore{
client: rdb,
codec: sessions.SimpleCodec{Key: []byte("your-secret-key")},
}
// 然后传给中间件
r.Use(sessions.Sessions("mysession", store))
- 必须自己实现
redisStore.Get/Set/Delete方法，满足sessions.Store接口 -
sessions.SimpleCodec是最轻量的加解密方式，别漏掉Key字段，否则解密失败导致 session 为空 - Redis key 命名默认是
sessions:<session-id></session-id>，可自定义前缀，避免和其他业务 key 冲突
Session ID 怎么生成、存哪、过期怎么管？
Session ID 由 sessions 包自动生成（UUID v4），默认写进 HTTP Cookie，名字是 session_id（可改），值是加密后的 ID；真实数据存在 Redis 里，生命周期靠两个时间控制：Cookie 过期（MaxAge）和 Redis key TTL（Expiration）。
- 如果不设
Options.MaxAge，浏览器关掉就失效；设成负数表示永不过期（不推荐） - Redis TTL 必须显式设置，比如
store.Options(sessions.Options{MaxAge: 3600})，否则默认 0（永不过期），Redis 里 key 不自动删 - 注意时区：Redis TTL 是秒级，
MaxAge单位也是秒，别误写成毫秒 - 用户登出时，务必调用
session.Clear()+session.Save()，否则 Redis 里残留 key，且下次请求仍能读到旧数据
为什么登录后拿不到刚 set 的值？
典型现象：在 handler 里 session.Set("user_id", 123)，紧接着 session.Get("user_id") 返回 nil —— 不是 bug，是 sessions 的设计机制：所有 Set/Delete 操作只在 session.Save() 被调用后才真正写入底层 store（Redis），而 Get 读的是当前内存快照。
- 正确顺序：先
Set，再Save，之后的Get才能读到最新值（同一请求内） - 中间件默认在 handler 返回后自动调用
Save，所以跨请求肯定能读到；但同请求内想立刻读，就得手动Save并重新Get - 更安全的做法是：只在需要持久化的点调
Save，其余读操作依赖内存快照，避免频繁写 Redis
Session 数据结构简单、无事务、不支持嵌套修改，别把它当数据库用。真要共享状态，该上 Redis Hash 或单独 key 就上。
