Go 语言中的 Cookie 和 Session 是如何管理的？-Golang-PHP中文网

go 语言需自行实现 session 管理，http.setcookie 必须在响应头发送前调用且属性严格匹配；gorilla/sessions 需手动初始化、获取、修改并显式 save；存储层须统一 ttl、时区与 id 安全生成。

go 语言本身不提供开箱即用的 session 管理，http.setcookie 和 r.cookie 只负责 cookie 的传输层操作；session 是服务端概念，必须由开发者自行组合存储、过期、签名等环节——要么手写，要么用 gorilla/sessions 这类成熟库。

不是代码没调用，而是响应头已发送或属性错配导致浏览器直接丢弃：

必须在任何 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" 字符串会被忽略

它不是“自动 Session”，而是帮你把签名、加密、存储解耦的可靠封装。关键动作必须手动触发：

Ai Session Analysis

用于分析本地AI编程助手会话数据（如Claude Code、Codex、Kimi Code）。当用户请求分析编程会话时触发。

下载

初始化 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:"），避免和业务键冲突

手写不难，但几个边界条件一错，线上就出问题：

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 本身只是随机字符串，不要当成唯一主键依赖，真正防冲突靠存储层原子写（如 Redis SET key val EX 3600 NX）
前端跨域请求时，fetch 要加 credentials: "include"，Axios 要设 withCredentials: true，否则浏览器根本不会发 Cookie