gorilla/sessions 是最省心也最安全的 go session 方案，但需严格遵循安全配置：密钥≥32字节、显式设置 httponly/secure/samesite、登录后重生成 id 并清旧 cookie、存储层 ttl 与 maxage 一致、禁用纯 cookie 存储敏感数据。
gorilla/sessions 是最省心也最安全的选择
Go 标准库不提供 Session 模块，手写容易漏掉关键安全配置。直接用 gorilla/sessions 能规避 90% 的常见漏洞，前提是正确初始化和使用。
-
cookiestore.NewStore()的密钥长度必须 ≥ 32 字节（推荐 64），否则运行时 panic -
store.Options必须显式设置：HttpOnly: true、Secure: true（生产环境 HTTPS 下）、SameSite: http.SameSiteLaxMode -
MaxAge建议设为正整数（如86400），避免依赖浏览器默认行为；设为0表示关闭时失效，但登录后重生成必须用这个值清旧 Cookie - Session 数据本身只签名不加密，若存敏感字段（如 token），需额外用
gorilla/securecookie包加密
登录后必须重生成 Session ID，否则会话固定
用户首次访问时，sessions.Get(r, "mysession") 会自动创建新 Session，此时 ID 尚未绑定身份，可被攻击者预设。登录验证通过后，不重生成 ID 就等于把“临时门票”当“正式工牌”用。
- 调用
session.Options.MaxAge = 0强制使旧 Cookie 失效 - 清空
session.Values，重新赋值用户数据（不要复用旧值） - 最后调用
session.Save(r, w)写入新 ID 和新数据 - 这三步缺一不可，跳过任意一步都可能触发
Session Fixation
自定义存储（Redis/BoltDB）时的三个隐形陷阱
换掉默认的 Cookie-only 存储后，很多问题不会立刻报错，但会在压测或上线后暴露。
- Redis key 的
EXPIRE时间必须和session.Options.MaxAge完全一致，否则出现“Cookie 已过期但 Redis 中数据还在”，导致逻辑错乱 - BoltDB 等文件存储必须加读写锁（
sync.RWMutex），否则并发写入会 panic ——sync.Map不适用这类持久化场景 - 不要自己写定时 goroutine 扫描过期 Session：既难保证实时性，又增加 CPU 开销；应依赖 Redis 的 TTL 或 BoltDB 的惰性删除（查时判断
ExpiresAt）
为什么不能只靠 Cookie 存 Session 数据？
把用户 ID、角色、token 全塞进 Cookie 并 base64 编码，是新手最常犯的错。看似省事，实则放弃所有服务端控制权。
- Cookie 可被客户端篡改（即使设了
HttpOnly，签名缺失照样伪造） - 没有服务端过期控制，用户登出后 Cookie 仍有效，无法强制销毁
- 无法做 IP 变化检测、设备指纹比对等增强风控动作
- 一旦密钥泄露，所有 Cookie 值可被解密或重放 —— 而服务端存储还能加审计日志和限流
gorilla/sessions 就很稳；写错一处，整个链路就可能被绕过。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
