Go标准库不提供Session管理，仅用http.Cookie传ID；真正用户状态需自行实现存储、校验与过期清理，硬写明文session_id是常见错误起点。
Go 标准库不提供 Session 管理，http.Cookie 只负责传一个 ID；真正要存用户状态，必须自己配存储、校验、过期清理——硬靠 http.SetCookie 写明文 session_id 是常见错误起点。
为什么 r.Cookie("session_id") 总是返回 nil
不是没设 Cookie，而是浏览器压根没发回来。最常踩的坑是属性错配：
-
Secure: true却跑在http://localhost—— 浏览器直接丢弃，开发时务必设Secure: false -
SameSite值写成"lax"或"None"（小写或拼错）—— 整个 Cookie 被忽略，必须用http.SameSiteLaxMode这类常量 -
Domain设成".example.com"（带前导点）—— 错，应写"example.com"；本地开发时Domain必须留空，填了反而失效 -
Path默认是请求路径的父路径（比如请求/api/login，默认Path="/api"），要全站生效得显式设为Path="/"
gorilla/sessions.Save() 为什么总把 MaxAge 重置成 0
session.Save(r, w) 每次调用都会重写 Cookie，且默认行为是：如果没显式设置 session.Options.MaxAge，就按 0 处理（即“浏览器关闭即失效”）。这不是 bug，是设计使然。
- 只在 Session 数据真正修改后才调用
session.Save()，中间件里无条件 save 会干扰并发和客户端缓存 - 想维持原有过期时间，必须每次 save 前显式赋值：
session.Options.MaxAge = 3600 -
MaxAge = 0不代表安全边界，它依赖浏览器实现，不能用于权限控制
Redis 存 Session 为什么过期不一致
gorilla/sessions 的 MaxAge 只管客户端 Cookie 过期，完全不管 Redis 里那条数据。服务端数据不过期，就会出现“Cookie 已删但 Redis 还有残留”，或者“Cookie 没过期但服务端已清数据”。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 用
redisstore.NewRedisStore()时，必须手动对齐 TTL：既设store.Options.MaxAge，又在 Redis 写入时带SETEX sess:abc123 3600 {...} - 所有 Session key 必须加统一前缀（如
"sess:"），否则和业务 key 混在一起，没法批量清理 - 数据库方案中，
expires_at字段必须存 UTC 时间，且查询时用WHERE expires_at > NOW()，别用本地时区
敏感数据能不能塞进 session.Values
能塞，但默认不加密——gorilla/sessions 默认只签名（防篡改），不加密（防窥探）。如果你写了 session.Values["user_id"] = 123，攻击者抓包拿到 Cookie 后，用 securecookie 解码就能看到明文。
- 启用 AES 加密需额外配置
securecookie：传入 16/24/32 字节blockKey，并调用securecookie.CodecsFromPairs() - 密钥长度不能凑合：硬编码
"mykey"会静默降级为不安全的 HMAC-SHA1，必须 ≥32 字节 - 删除字段用
delete(session.Values, "token")，不是session.Values["token"] = nil——后者仍会序列化进 Cookie
Session 安全真正的复杂点不在加密或存储，而在两端 TTL 对齐、密钥轮换机制、以及登录成功后强制刷新 session ID 防固定攻击——这些细节一旦漏掉，前面所有配置都可能白做。
