必须显式传入redis.options结构体初始化client再交由redis.newstore，不可直接传地址字符串；session id不等于redis key，清除须用session.clear()+save()或store.destroy()；cookie名需通过session.options().name显式设置，不可依赖sessions("name")参数；禁止混用gorilla/sessions与gin-contrib/sessions。
gin-contrib/sessions 连 Redis 必须显式传入 redis.Options
直接用 redis.NewStore 会 panic，因为新版 github.com/gin-contrib/sessions/redis 不再接受地址字符串，而是要求传入 redis.Options 结构体。常见错误是照着旧文档写成 redis.NewStore("localhost:6379", "password", 0)，这在 v1.2+ 版本里已失效。
正确做法是先初始化 redis.Client（推荐用 go-redis/redis/v9），再把它的 Options() 提交给 session store：
client := redis.NewClient(&redis.Options{
Addr: "localhost:6379",
Password: "",
DB: 0,
})
store := redis.NewStore(client)
注意：redis.NewStore 接收的是 *redis.Client，不是连接池或 URL 字符串；如果用错类型，编译不报错但运行时 session.Save() 会静默失败。
Session ID 不等于 Redis key，别手动拼接 key 去删数据
很多人误以为 session.ID() 就是 Redis 里的 key，然后在登出时写 client.Del(ctx, "session_"+session.ID()) ——这是错的。实际 key 是由 store 内部生成的，格式类似 session:abc123def456，且带前缀和编码逻辑。
正确清除方式只有两个：
- 调用
session.Clear()+session.Save()，它会清空值并让 Redis key 过期 - 调用
store.Destroy(session.ID())，这是 store 提供的专用销毁方法
手动删 key 不仅可能删错，还会绕过 store 的清理逻辑（比如未同步删除 cookie 或未触发钩子），导致下次请求仍能读到残留数据。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
Cookie 名和 Session name 不是同一个东西
初始化中间件时写的 sessions.Sessions("mysession", store) 中的 "mysession" 是 session 实例名，用于内部上下文标识，**不会**自动变成 Cookie 名。真正发给浏览器的 Cookie 名默认是 session_id，但可以覆盖：
r.Use(sessions.Sessions("mysession", store))
// 后续 handler 中：
session := sessions.Default(c)
session.Options(sessions.Options{
Path: "/",
MaxAge: 3600,
HttpOnly: true,
Secure: false, // 开发环境可设 false
})
如果你希望 Cookie 名是 GOSESSID，必须在 session.Options() 里显式设置 Name 字段：
session.Options(sessions.Options{
Name: "GOSESSID",
// 其他选项...
})
漏掉这步，前端拿不到你期望的 Cookie 名，后续鉴权就断链。
gorilla/sessions 和 gin-contrib/sessions 混用会出问题
虽然两者底层都基于 gorilla/sessions 的接口，但 gin-contrib/sessions 对 store 做了封装和适配。如果你在同一个项目里既 import github.com/gorilla/sessions 又 import github.com/gin-contrib/sessions，然后混用 sessions.NewCookieStore 和 gin-contrib/sessions.Default(c)，会出现 context key 冲突、session 无法获取等问题。
建议统一选一个：
- 纯 Gin 项目 → 用
gin-contrib/sessions，它对 Gin context 集成更干净 - 需要跨框架复用 session logic → 用
gorilla/sessions，但要自己处理 Gin context 注入
最常被忽略的一点：二者注册 session 实例到 context 的 key 不同（gin-contrib 用 DefaultKey = "gin-contrib/sessions"，gorilla 默认不用 Gin context），混用时 sessions.Default(c) 拿到的可能是 nil。
