直接用http.setcookie存session不安全，因cookie明文传输易被窃取伪造，且若将role等敏感字段直存未加密cookie等于交出控制权；gorilla/sessions通过aes+hmac加密签名防篡改泄露，需32字节以上密钥、httponly=true、secure=true及samesite=lax/strict。
为什么直接用 http.SetCookie 存 Session 不安全
因为 Cookie 默认明文传输，攻击者抓包就能看到 session_id=abc123，甚至伪造修改。更危险的是，如果把用户角色、权限等敏感字段（如 role=admin）直接塞进 Cookie 且未加密，等于主动交出控制权。
Go 标准库不提供开箱即用的加密会话支持，gorilla/sessions 是最常用的选择，它底层用 securecookie 实现 AES+HMAC 加密签名，能防篡改、防泄露。
- 必须显式设置密钥：至少 32 字节 AES 密钥 + 32 字节 HMAC 密钥，不能硬编码在代码里（应从环境变量或配置文件加载）
- 务必禁用
http.Cookie.HttpOnly=false—— 否则 JS 可读写，XSS 一打一个准 - 记得设
SameSite=Strict或Lax，缓解 CSRF
如何用 gorilla/sessions 创建加密 Cookie 会话
不是简单调用 NewCookieStore 就完事。密钥生成和存储方式决定安全性上限：
- 用
securecookie.GenerateRandomKey(32)生成密钥，别手敲十六进制字符串（易短、易重复） - 密钥必须持久化保存（如配置文件），重启服务后不能变，否则所有旧 Cookie 全失效
- 示例初始化代码：
var store = sessions.NewCookieStore( []byte(os.Getenv("SESSION_ENCRYPTION_KEY")), // AES key []byte(os.Getenv("SESSION_AUTHENTICATION_KEY")), // HMAC key ) store.Options = &sessions.Options{ Path: "/", MaxAge: 86400, HttpOnly: true, Secure: true, // 生产环境必须为 true（HTTPS 下才发送） SameSite: http.SameSiteLaxMode, }
存取用户数据时哪些字段不能放、哪些必须转义
Session 本质是服务端状态的“客户端投影”，不是数据库替代品。加密 Cookie 有 4KB 上限，超长会截断或报错 http: named cookie too long。
- 禁止存原始密码、token、私钥 —— 即使加密，泄露后仍需立即轮换密钥
- 避免存大结构体：先
json.Marshal再存，但注意中文等 UTF-8 字符会占更多字节 - 用户 ID 可以存，但建议用随机
session_id关联后端数据库，只存user_id和expires_at时间戳 - 从
session.Values读取时，务必类型断言并检查是否为nil：uid, ok := session.Values["user_id"].(int)，否则 panic
为什么 Save() 调用失败时会静默丢数据
session.Save(r, w) 不仅写 Cookie，还负责计算 HMAC 签名、AES 加密、Base64 编码。一旦出错（比如密钥长度不对、HTTP 头已写入），它只返回 error，但不会 panic，也不自动重试。
- 必须检查返回值：
if err := session.Save(r, w); err != nil { log.Printf("session save failed: %v", err) } - 常见错误
http: invalid byte in cookie value：说明存了非法字符（如 \x00、\r、\n），JSON 序列化前用strings.TrimSpace清理 - 开发时关掉
Secure=true，否则本地 HTTP 环境下 Cookie 直接被浏览器丢弃，调试无从下手
加密会话真正的难点不在代码几行，而在于密钥生命周期管理、过期策略与后端存储的协同，以及对“客户端可篡改”这一前提的持续敬畏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
