Go的http.SetCookie失效主因是响应已写入或域名/路径不匹配；必须在Write/WriteHeader前调用，Domain不能带前导点，开发时localhost需留空Domain，Path显式设为/可全站生效。
Go标准库http.SetCookie为什么设不上Cookie
浏览器收不到Set-Cookie响应头，通常不是代码没调用，而是响应已写入或域名/路径不匹配。Go的http.ResponseWriter一旦调用Write或WriteHeader（非200时也触发隐式写入），后续再调用http.SetCookie就完全失效——它只是往响应头里塞字段，不负责检查状态。
- 必须在任何
Write、WriteHeader之前调用http.SetCookie -
Domain字段不能带前导点（如.example.com是错的，应写example.com），否则现代浏览器直接丢弃 -
Path默认是请求路径的父路径，比如请求/api/login，默认Path为/api；若希望全站有效，显式设为/ - 开发时用
localhost测试，Domain必须留空，填了反而失效
用gorilla/sessions管理Session时，Store.Get返回nil或空session.Values
这不是Session丢失，而是键名不一致或Store未正确初始化。这个包不自动创建Session，Get只查已有记录；如果没存过，就返回新Session（值为空），但很多人误以为“没拿到数据=出错了”。
- 确保每次调用
session.Save(r, w)，且在Write之后——它会真正写入Cookie；漏掉这步，下次Get还是空 -
session.Name()返回的是Cookie名，默认session，但前端若手动删了这个Cookie，Get就会新建一个，看起来像“数据丢了” - 使用
cookiestore.NewCookieStore([]byte("your-secret-key"))时，密钥不能太短（至少32字节），否则加密失败，Save静默失败 - 开发环境建议加
store.Options = &sessions.Options{HttpOnly: false, Secure: false}，避免HTTPS强制导致本地失效
自建Session存储（Redis/DB）时，session.ID()重复或过期不清理
ID重复极少发生，真正的问题是过期逻辑没对齐：内存Store靠GC，而Redis靠TTL，数据库靠定时任务。如果应用重启，内存Session全丢，但Redis里还留着旧ID，用户可能撞上残留会话。
Remix V2 Meta Sessions Review
下载
审查 Remix v2 代码中的 v1 形态 meta 导出（v2 中为破坏性变更），cookie 安全漏洞（httpOnly、secure、密钥轮换），认证门位于错误层级，以及其他
- 不要依赖
session.ID()做唯一性校验，它只是编码后的随机字节；真正防冲突靠存储层的原子写（如RedisSET key val EX 3600 NX） - 用Redis时，务必给每个Session键加统一前缀（如
sess:），避免和业务键冲突，也方便批量清理 - 数据库方案中，
expires_at字段必须用UTC时间，且查询时用WHERE expires_at > NOW() AT TIME ZONE 'UTC'，否则时区错位导致“明明没过期却查不到” - 无论哪种后端，
session.Save都该带Options.MaxAge，它会同时控制Cookie过期和后端存储TTL，别只设一边
HTTP/2下SameSite=Strict导致登录后跳转丢失Session
这是真实踩坑场景：用户登录后重定向到首页，但首页拿不到Session。问题不在Go代码，而在SameSite策略与重定向链路的交互。Chrome等浏览器对Strict执行极严：只要跳转来源不是同站（比如从auth.example.com跳到www.example.com），就不带Cookie。
立即学习“go语言免费学习笔记（深入）”；
- 生产环境优先用
SameSite=Lax（gorilla/sessions默认值），它允许GET跳转携带Cookie，覆盖绝大多数登录流程 - 若必须用
Strict，确认所有跳转都在同一二级域下（如全是app.example.com子路径），且反向代理没改写Host头 - 调试时用浏览器开发者工具的Application → Cookies面板，直接看对应域名下有没有
sessionCookie，比抓包更快 -
Secure选项必须开启（即Options.Secure = true）才能配合SameSite生效，否则浏览器忽略SameSite设置
Session ID本身不敏感，但它的绑定关系（比如和用户ID的映射）才是关键。很多人花大力气加密ID，却忘了后端查数据库时没加索引，或者Redis没设TTL，这才是实际压垮服务的点。
