Go中安全设置Cookie需同时启用HttpOnly、Secure和SameSite；使用gorilla/sessions时须正确配置Store与密钥，显式调用session.Save()，登出时须同步清理后端存储与Cookie。
Go标准库的http.Cookie怎么安全设置和读取
Go原生不带Session支持，但http.SetCookie和r.Cookie足够处理基础Cookie逻辑。关键不是“能不能设”，而是“设得对不对”。
常见错误是忽略HttpOnly、Secure和SameSite——这三者缺一就可能被XSS或CSRF利用。
-
HttpOnly: true：阻止JS访问，防XSS窃取 -
Secure: true：仅HTTPS传输，开发时若用HTTP需设为false（但上线必须true） -
SameSite: http.SameSiteLaxMode或http.SameSiteStrictMode：缓解CSRF，默认SameSite: ""等于不设，等同于开放攻击面
cookie := &http.Cookie{
Name: "session_id",
Value: "abc123",
Path: "/",
HttpOnly: true,
Secure: true, // 生产环境强制开启
SameSite: http.SameSiteLaxMode,
MaxAge: 3600,
}
http.SetCookie(w, cookie)
用gorilla/sessions实现服务端Session管理
自己手写Session存储极易出错（比如并发写入、过期清理、密钥轮换）。社区事实标准是github.com/gorilla/sessions，它把加密、签名、存储解耦得很清楚。
核心是两个概念：Store（存哪）和Session（怎么用）。别直接操作Cookie值，始终走session.Values接口。
立即学习“go语言免费学习笔记（深入）”；
- 内存Store仅适合开发调试，
cookiestore.NewCookieStore([]byte("your-32-byte-secret"))里的密钥必须≥32字节，否则启动报key must be 32 bytes long - 生产环境务必换
redisstore或postgresstore，避免重启丢Session - 调用
session.Save(r, w)才会真正写入响应头；漏掉这步，前端收不到新Cookie
store := cookiestore.NewCookieStore([]byte("12345678901234567890123456789012"))
session, _ := store.Get(r, "session-name")
session.Values["user_id"] = 123
session.Save(r, w) // 必须显式调用
为什么gorilla/sessions默认不自动过期Redis中的Session
它只管Cookie生命周期（MaxAge），不管后端存储。Redis里Session永不过期，除非你手动删或依赖Redis自身的EXPIRE策略。
典型陷阱：用户登出时只删了Cookie，但Redis里session_id还活着，别人拿到旧ID就能复用会话。
- 登出必须两步：清空
session.Values+ 调用session.Save()+ 主动删除Redis中对应key - 若用
redisstore，构造Store时传入redis.Options{Addr: "...", Password: "", DB: 0}，再通过store.(*redisstore.RedisStore).Options().MaxAge控制TTL - 更稳妥做法：所有Session写入Redis时都带
EXPIRE，例如用redis.Client.SetEX(ctx, key, value, time.Hour)自行封装
自定义Session中间件要注意的并发与上下文传递
很多人写中间件把*sessions.Session塞进r.Context()，但没注意session.Save()需要http.ResponseWriter，而中间件里通常只有http.Handler的next.ServeHTTP(w, r)之后才真正写出响应。
结果就是：Session改了，但Save()没被执行，前端Cookie还是旧的。
- 不要在中间件里直接
session.Save()——此时w可能已被包装（如gzip），导致Header写失败 - 正确做法：用
context.WithValue(r.Context(), sessionKey, session)传下去，在业务Handler末尾统一session.Save(r, w) - 如果用了
chi或gin，优先用它们的Context机制，避免自己造WithValue嵌套过深
Session不是“设完就完”，从生成、传输、存储到销毁，每一步都有明确责任边界。最容易被跳过的，是登出时后端存储的清理和Cookie的彻底失效。
