http.SetCookie 设不上主因是响应头已写入，必须在 WriteHeader 或 Write 前调用；Go 无内置 Session，需自行用 Cookie ID + 服务端存储实现；MaxAge 优先于 Expires，Secure/HttpOnly/SameSite 缺一不可。
Go 的 http.SetCookie 为什么设不上？
常见现象是调用 http.SetCookie 后浏览器没收到 Cookie，或刷新后消失。根本原因不是函数没执行，而是响应头已写入（即 WriteHeader 已触发或 Write 已输出内容）——HTTP 规范要求 Cookie 必须在响应头中发送，一旦 body 开始写入，header 就锁定。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确保在任何
ResponseWriter.Write或隐式WriteHeader(200)调用前设置 Cookie - 如果用了模板渲染（如
tmpl.Execute），必须在它之前调用http.SetCookie - 检查中间件是否提前写了响应（比如日志中间件误调用了
w.Write） - 用
curl -v或浏览器 DevTools 的 Network 标签页确认响应头中是否含Set-Cookie
Session 不是标准库内置概念，别直接搜 http.Session
Go 标准库的 net/http 没有 Session 类型，也没有自动 Session 管理。所谓“Go 实现 Session”，本质是开发者自己用 Cookie + 服务端存储（内存/map/Redis）组合完成的逻辑封装。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要依赖
http.Request自带 “session 字段”——它不存在 - 典型做法：生成唯一
session_id写入 Cookie，再用该 ID 查服务端 map 或 Redis 中的用户数据 - 注意并发安全：若用
map[string]interface{}存 session，必须配sync.RWMutex - 避免把敏感信息（如密码、token）直接塞进 Cookie 值；应只存无意义的 ID，查表取数据
http.Cookie 的 MaxAge 和 Expires 别混用
这两个字段控制 Cookie 过期，但行为不同：MaxAge 是秒数（int），由客户端按本地时间计算；Expires 是绝对时间（time.Time），由服务端指定，客户端按自身时钟比对。现代浏览器优先用 MaxAge，若两者都设，MaxAge 覆盖 Expires。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 设短期会话（如 30 分钟）用
MaxAge: 30 * 60，更可靠 - 设长期登录（如 7 天）也推荐
MaxAge，避免客户端时间偏差导致提前过期 -
MaxAge: 0表示“会话级 Cookie”，关闭浏览器即失效；MaxAge: -1才是立即删除（等价于Expires = past time） - 别同时设
MaxAge和Expires，容易互相覆盖，调试困难
Secure、HttpOnly、SameSite 这三个字段漏一个就可能出问题
它们不是可选装饰，而是关键安全边界。漏设 Secure 在 HTTPS 站点会导致 Cookie 不发送；漏 HttpOnly 让 XSS 更容易窃取 session；漏 SameSite 可能引发 CSRF 或跨站登录态异常。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 生产环境必须设
Secure: true（仅 HTTPS 传输），开发时若用 HTTP，先关掉它，否则 Cookie 直接被浏览器丢弃 - 只要 Cookie 存的是 session_id，一律设
HttpOnly: true，禁止 JS 读取 -
SameSite推荐显式设为Lax（默认值，防大部分 CSRF）或Strict（更严，但可能影响 OAuth 流程）；别留空，旧浏览器当None处理，反而危险 - 测试时用
curl -I检查响应头里Set-Cookie是否包含这些属性，别只信代码写了
真正难的不是写几行 http.SetCookie，而是想清楚每个字段在什么网络环境、什么客户端版本、什么攻击场景下是否生效。浏览器和中间代理对 Cookie 的解析规则，远比文档写的零碎。
