go标准库无内置session支持，必须借助gorilla/sessions等第三方库实现；需全局复用store、显式调用save、严格配置httponly/secure/samesite、redis存储须对齐ttl与maxage，并在登录后重生成session id以防会话固定。
Go标准库net/http里没有内置Session支持
Go语言本身不提供开箱即用的Session管理，http.ServeMux和http.Handler都只处理单次请求，服务端无默认状态存储。你不能像PHP或Django那样直接调用$_SESSION或request.session。必须自己组合cookie、存储后端和生命周期控制——这是所有Go Session方案的起点。
常见错误是直接用map[string]interface{}全局存session数据：并发读写会panic，且进程重启就全丢。真正可用的方案必须满足三点：线程安全、可持久化、能校验签名/加密。
用gorilla/sessions实现带Redis后端的Session
这是目前最稳定、文档最清晰的第三方方案，支持内存、文件、Redis等多种store，且默认启用secure cookie和HTTP-only标志。关键不是“怎么装”，而是“怎么配才不出问题”：
-
Store实例必须全局复用（比如放在main()里初始化后传入handler），每次请求都调用store.Get(r, "session-name")获取*sessions.Session - Redis store需用
github.com/gorilla/sessions/redis子包，连接字符串格式为redis://localhost:6379/0；若用密码，要写成redis://:password@localhost:6379/0 - 务必设置
Options.HttpOnly = true和Options.Secure = true（后者在HTTPS下才生效，开发时可设false但别提交） - Session ID默认存在cookie里，名字是
session-name（你传给Get()的第一个参数），不要和其它中间件冲突
示例关键片段：
store, _ := redis.NewStore(10, "tcp", "localhost:6379", "", []byte("your-secret-key"))
store.Options = &sessions.Options{
Path: "/",
MaxAge: 86400,
HttpOnly: true,
Secure: false, // 开发环境先关掉
}
http.HandleFunc("/login", func(w http.ResponseWriter, r *http.Request) {
session, _ := store.Get(r, "auth-session")
session.Values["user_id"] = 123
session.Save(r, w) // 必须显式调用，否则不写cookie也不存Redis
})
用户认证流程中Session容易被绕过的三个点
Session只是状态容器，不等于认证。很多项目把session.Values["user_id"]一设就认为用户已登录，结果埋下越权隐患：
- 没校验用户是否存在：
user_id可能已被删除，后续逻辑应查DB确认该ID对应有效用户 - 没绑定请求上下文：攻击者复制合法cookie发到另一台机器（如内网测试服），若Redis共享且没加IP/User-Agent绑定，就会成功冒用
- 没清理失效Session：用户登出只删了cookie，但Redis里key还活着；应调用
session.Options.MaxAge = 0再Save()，或直接store.Destroy(r, w)
更稳妥的做法是在登录成功后生成一个随机session_token存进DB（关联user_id和expires_at），每次请求从Session里取session_token去查DB，而不是直接信user_id。
自定义Session中间件时别忽略http.StripPrefix对路径的影响
如果你用http.StripPrefix("/api", handler)挂载路由，而Session cookie的Path设成了/api，那么浏览器在访问/api/login时会发送cookie，但/根路径下前端JS发起的fetch("/user")不会带这个cookie——因为Path不匹配。
解决方案只有两个：
- 统一设
Options.Path = "/"（推荐，除非你明确需要隔离不同子路径的Session） - 或者在前端fetch时手动加
credentials: "include"，并确保后端CORS头允许凭据（Access-Control-Allow-Credentials: true）
这个细节在前后端分离项目里特别容易漏，现象是“登录接口返回成功，但后续接口一直401”，实际是cookie根本没发过去。
Session机制本身不复杂，难的是在各种部署场景（多实例、HTTPS切换、CDN缓存、前端路由）下保持一致的行为。每次加新功能前，先问一句：这个Session值，是不是在任意一次请求里都能被正确读取、验证、销毁？
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
