Go 语言需自行实现 Session 管理，http.SetCookie 必须在响应头发送前调用且属性严格匹配；gorilla/sessions 需手动初始化、获取、修改并显式 Save；存储层须统一 TTL、时区与 ID 安全生成。
go 语言本身不提供开箱即用的 session 管理，http.setcookie 和 r.cookie 只负责 cookie 的传输层操作；session 是服务端概念，必须由开发者自行组合存储、过期、签名等环节——要么手写，要么用 gorilla/sessions 这类成熟库。
为什么 http.SetCookie 经常设不上
不是代码没调用，而是响应头已发送或属性错配导致浏览器直接丢弃：
- 必须在任何
w.Write、json.NewEncoder(w).Encode()或隐式w.WriteHeader()（比如返回 404）之前调用，否则 header 缓冲区已提交，SetCookie无效 -
Domain字段不能带前导点（.example.com错，应写example.com）；开发时用localhost必须留空Domain，填了就失效 -
Path默认是请求路径的父级（如请求/api/login，默认Path为/api），全站生效需显式设为/ -
Secure: true在 HTTP 环境下会让浏览器拒绝发送该 Cookie，本地调试务必设为false -
SameSite值必须是http.SameSiteLaxMode、http.SameSiteStrictMode或http.SameSiteNoneMode（注意大小写），写成"lax"或"none"字符串会被忽略
如何安全地用 gorilla/sessions 管理 Session
它不是“自动 Session”，而是帮你把签名、加密、存储解耦的可靠封装。关键动作必须手动触发：
- 初始化
store := sessions.NewCookieStore([]byte("your-32-byte-secret-key"))，密钥必须 ≥32 字节（用openssl rand -base64 32生成），硬编码或太短会导致静默失败 -
session, _ := store.Get(r, "session-name")不会报错，但若 Cookie 不存在或校验失败，返回的是新 Session（Values为空），不是“获取失败” - 修改
session.Values后，必须显式调用session.Save(r, w)才真正写入响应头；漏掉这步，前端收不到更新 - 登录成功后防固定攻击：先调
session.Options.MaxAge = 0清除旧 Cookie，再session.Save(r, w)，然后store.New(r, "session-name")拿新 Session - 生产环境别用
NewCookieStore，改用redisstore.NewRedisStore，并给 key 加统一前缀（如"sess:"），避免和业务键冲突
自己实现 Session 存储时最容易忽略的点
手写不难，但几个边界条件一错，线上就出问题：
-
MaxAge控制客户端行为，和服务端 TTL 完全无关。Redis 中必须用SETEX或SET key val EX 3600显式设 TTL，不能只靠 Cookie 过期 - 数据库方案中
expires_at字段必须存 UTC 时间，查询时用WHERE expires_at > NOW() AT TIME ZONE 'UTC'，否则时区错位导致“查不到未过期 session” - Session ID 必须用
crypto/rand.Read生成，禁用math/rand；ID 本身只是随机字符串，不要当成唯一主键依赖，真正防冲突靠存储层原子写（如 RedisSET key val EX 3600 NX） - 前端跨域请求时，fetch 要加
credentials: "include"，Axios 要设withCredentials: true，否则浏览器根本不会发 Cookie
最常被跳过的其实是时间对齐：Cookie 的 MaxAge、Redis 的 TTL、数据库的 expires_at、甚至日志里记录的“过期时间”，四者必须一致，差一秒都可能造成用户莫名其妙登出或会话残留。
