Go标准库无session，需用gorilla/sessions等第三方包；须签名加密、服务端校验敏感数据、对齐cookie与存储过期时间、全局复用store、显式调用Save、设HttpOnly/Secure、Redis存struct时优先json序列化、过期处理需前后端协同。
Go 里没有内置 session，别直接 import “net/http/session”
Go 标准库压根没提供 session 类型——这是很多人卡住的第一步。你搜到的教程里写的 session，全是第三方包封装的，比如 gorilla/sessions 或 gofiber/fiber 自带的中间件。标准 http.ServeMux 和 http.Handler 只管请求/响应，状态得自己扛。
常见错误现象：import "net/http/session" 报错、undefined: session、用 http.SetCookie 手搓 ID 却忘了签名校验，结果被篡改 user_id=123 直接提权。
- 必须选一个有签名+加密能力的 session 包，
gorilla/sessions是最稳的通用选择 - 不要把敏感数据（如角色、权限）只存在客户端 cookie 里，哪怕加了签名；关键字段仍要服务端查库比对
- cookie 的
MaxAge和 session 存储（如 Redis）的过期时间要对齐，否则出现“cookie 没过期但服务端找不到 session”的假失效
用 gorilla/sessions 存用户登录态的最小可行写法
不是配一堆中间件，而是抓住三个动作：创建 store → 获取 session → 读写 Values。其它都是可选项。
import "github.com/gorilla/sessions"
var store = sessions.NewCookieStore([]byte("your-secret-key-here"))
func loginHandler(w http.ResponseWriter, r *http.Request) {
session, _ := store.Get(r, "auth-session")
session.Values["user_id"] = 123
session.Values["logged_in"] = true
session.Save(r, w) // 这行才真正写 cookie
}
-
store必须全局复用，不能每次 handler 都new一个，否则密钥不一致导致解不出 cookie -
session.Save(r, w)必须显式调用，不调就不会发 cookie；且只能在 header 未写出前调用，否则报http: multiple response.WriteHeader calls -
session.Options要设HttpOnly: true和Secure: true（HTTPS 环境），防 XSS 窃取
Redis 存 session 时，gorilla/securecookie 和序列化容易搞混
用 Redis 不是为了“存得快”，而是为了解决多实例部署下的 session 共享问题。但很多人以为只要换 NewRedisStore 就完事，结果发现值读出来是 map[interface{}]interface{} 或直接 panic。
立即学习“go语言免费学习笔记（深入）”；
- 根本原因是
gorilla/sessions默认用gob编码，而gob对 struct 字段要求严格：必须导出（首字母大写）、不能有循环引用 - 如果存的是
map[string]interface{}或简单类型（string/int），没问题；但存自定义 struct 前，先加json.Marshal再存字符串更省心 - Redis key 默认带前缀
sessions:，别手写DEL sessions:xxx清理，用store.MaxAge(-1)触发自动过期清理
Session 过期后，前端跳转逻辑和 HTTP 状态码怎么配合
浏览器不会因为 session 过期就自动重定向。你看到的“自动跳登录页”，全是前端 JS 或后端根据 session.Values 是否为空做的判断，不是协议行为。
- API 接口别返回 302 跳转，应统一返回
401 Unauthorized+ JSON 提示，由前端决定是跳页还是弹框 - Web 页面渲染场景下，middleware 中检查
session.Values["logged_in"] == nil后，直接http.Redirect(w, r, "/login", http.StatusFound) - 注意：重定向前务必先
session.Options.MaxAge = 0再Save()，否则旧 cookie 还带着，下次请求又恢复 session
session 最麻烦的从来不是怎么存，而是怎么让“过期”这件事在前后端之间达成一致理解——cookie 到期、服务端存储到期、业务逻辑认为该登出，这三者时间点稍有错位，就会出现闪退、重复登录、权限残留。
