Session管理是弥补HTTP无状态缺陷的核心机制，需服务器为用户创建唯一Session ID并存储状态数据，通过Cookie传递ID实现多请求间身份识别与状态关联。
Session 管理不是“加个包就能用”的功能，而是 HTTP 无状态本质下必须手动桥接客户端与服务端状态的一整套协同机制。直接用 gorilla/sessions 是最快路径，但跳过密钥配置、登录后 ID 重生成、存储 TTL 对齐这三步，等于裸奔。
为什么 NewCookieStore 必须传两个密钥
gorilla/sessions.NewCookieStore 默认启用签名+加密双机制，不是可选，是强制。只传一个 []byte（比如 NewCookieStore([]byte("key"))）会导致 session 数据明文写入 Cookie——你在浏览器开发者工具里能直接看到 user_id、role 等字段。
- authKey：用于 HMAC-SHA256 签名，防篡改；长度 ≥32 字节
- encKey：用于 AES-256 加密，防泄露；长度必须为 32 字节
- 两者都应从环境变量加载，绝不可硬编码；常见错误是 string 直接转
[]byte引入不可见字符，导致session.Values解析为空 map
登录成功后不调用 session.Load + session.Save 就等于送钥匙
用户首次访问时，sessions.Get(r, "mysession") 自动创建新 session，此时 ID 还没绑定身份，攻击者可预设该 ID 并诱导用户登录——这就是会话固定（Session Fixation）。
- 登录验证通过后，必须三步清旧建新：
session.Options.MaxAge = 0（删旧 cookie）、session.Values = map[string]interface{}{}（清空旧数据）、session.Save(r, w)（写新 ID 和新值） - 漏掉任意一步，旧 session ID 就继续有效，等同于把“临时门票”当“正式工牌”用
- 别依赖中间件自动 Save；
session.Save()必须显式调用，且必须在 handler 中所有响应操作（如http.Redirect、json.NewEncoder(w).Encode()）之前
换 Redis 存储后最常崩的三个点
换成 Redis 后不会立刻报错，但压测或高并发时大概率逻辑错乱甚至 panic。
立即学习“go语言免费学习笔记（深入）”；
- Redis key 的
EXPIRE时间必须和session.Options.MaxAge完全一致；否则出现“Cookie 没过期但 Redis 数据已删”，或反过来“Cookie 已过期但 Redis 还有数据” - 若自己封装 Store，别用
sync.Map做持久化层；它不保证磁盘写入顺序，多 goroutine 写 BoltDB 或文件时直接 panic；必须加sync.RWMutex - 别自己写 goroutine 扫描过期 session；既难保证实时性，又浪费 CPU；应依赖 Redis 的 TTL 或查时惰性判断
ExpiresAt
真正容易被忽略的是：session ID 的生命周期管理不在 Cookie 里，而在服务端存储与客户端 Cookie 的严格对齐上。哪怕密钥、加密、HTTPS 全对了，只要 Redis 的 EXPIRE 和 MaxAge 差 1 秒，就可能让用户卡在“已登录但权限丢失”的状态里。
