gorilla/sessions是当前最稳妥的go会话管理方案，但必须严格配对密钥长度（≥32字节）、httponly、secure和maxage四参数，登录后重生成session id，并同步服务端redis ttl与客户端maxage，缺一不可。
gorilla/sessions 是当前最稳妥的选择，但必须配对正确参数、登录后重生成 ID、服务端存储 TTL 与 MaxAge 严格同步——缺一不可。自己手写内存 session 容易漏掉过期清理或并发锁，用 sync.Map + 定时扫描也不如直接上 Redis 稳。
为什么不能用 net/http/session
Go 标准库压根没有 net/http/session 这个包。你 import 它会直接报错：import "net/http/session": cannot find package。所有搜到的“标准库 session 教程”，其实都是第三方封装。HTTP 本身无状态，http.Handler 只管收发，session 状态得你自己扛。
cookiestore.NewStore() 四个参数必须显式设全
用 gorilla/sessions 时，cookiestore.NewStore() 的初始化不是可选项——密钥长度、HttpOnly、Secure、MaxAge 四者缺一不可，否则轻则被 XSS 读取 cookie，重则触发会话固定攻击。
-
密钥必须 ≥ 32 字节（推荐 64），硬编码字符串不行，从环境变量加载更安全；长度不够运行时 panic -
HttpOnly: true防止 JS 读取 session id，堵住基础 XSS 提权路径 -
Secure: true生产环境必须启用，且只在 HTTPS 下生效；开发环境可设 false，但别提交到 prod -
MaxAge设为正整数（如86400），别设 0 除非你明确要“关浏览器即失效”；设 0 后登录重生成时必须用它清旧 cookie
登录后不重生成 Session ID 就等于送钥匙
用户首次访问时，sessions.Get(r, "mysession") 会自动创建新 session，此时 ID 是裸露的、未绑定身份的临时 ID。如果登录成功后不重生成，攻击者就能预设 ID 并诱导用户登录，完成会话固定（Session Fixation）。
- 调用
session.Options.MaxAge = 0清掉旧 cookie - 清空旧
session.Values，重新赋值用户数据，不要复用旧 map - 最后调用
session.Save(r, w)写入新 ID 和新数据
换 Redis 存储后三个最容易忽略的点
换成 redis.Store 后问题不会立刻报错，但压测或上线后大概率逻辑错乱：
- Redis key 的
EXPIRE时间必须和session.Options.MaxAge完全一致，否则出现“cookie 没过期但 Redis 数据已删”，或反过来“cookie 已过期但 Redis 还有数据” - 别自己写 goroutine 扫描过期 session：既难保证实时性，又浪费 CPU；应依赖 Redis 的 TTL 或查时惰性判断
ExpiresAt - 并发修改同一 session 时，
gin-contrib/sessions的Save()会无条件覆盖整条记录，A 改 cart_count、B 改 theme，后者直接冲掉前者；建议改用 Lua 脚本原子更新字段
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
