go中cookie会话管理需严格设置httponly、secure、samesite等字段防xss/csrf，服务端必须校验session id有效性并避免敏感信息明文存储，客户端应使用cookiejar自动管理cookie生命周期。
Go 中用 net/http.Cookie 管理会话状态，本质是「服务端生成唯一 session ID 存进 Cookie，再和服务端存储的用户数据做映射」——不能把敏感信息（如密码、token 明文）直接塞进 Cookie 值里，也不能依赖 Cookie 自身做完整校验。
设置 Cookie 时必须显式控制关键字段
仅调用 http.SetCookie(w, cookie) 不够，http.Cookie 结构体里几个字段不设好，会立刻暴露在 XSS、CSRF 或中间人攻击下：
-
HttpOnly必须为true：阻止 JavaScript 读取，防 XSS 窃取 session ID -
Secure在生产环境必须为true：确保只通过 HTTPS 传输，HTTP 下会被浏览器丢弃 -
SameSite推荐设为http.SameSiteStrictMode或http.SameSiteLaxMode：缓解 CSRF，尤其涉及表单提交或 GET 跳转时 -
Path设为"/"（除非你明确要限制子路径访问）；Domain一般留空，让浏览器自动匹配当前域名，填错会导致 Cookie 不发送 -
MaxAge比Expires更可靠：用秒数控制生命周期，避免时区/系统时间偏差问题；设为0是会话级 Cookie（关浏览器即失效），负数表示立即删除
读取和验证 Cookie 的常见陷阱
r.Cookie("session_id") 看似简单，但实际容易踩坑：
- 返回
err != nil不代表“没登录”，可能是 Cookie 过期、被篡改、或客户端禁用了 Cookie —— 不要直接重定向到登录页，先检查错误类型（比如http.ErrNoCookie可区分） - Cookie 值是纯字符串，**服务端必须校验其有效性**：比如查 Redis 是否存在该
session_id对应的用户数据、是否过期、是否被主动注销 - 不要信任
cookie.Value的任何结构（如 base64 编码的 JSON），它可能被恶意构造；解码前必须做签名验证（例如用hmac校验 MAC） - 若用
r.Cookies()批量读取，注意遍历顺序不保证，且同名 Cookie 可能有多个（虽然 RFC 不鼓励）
客户端发起请求时自动携带 Cookie 的正确姿势
如果你在 Go 里写 HTTP 客户端（比如模拟登录后调用 API），别手动拼 "Cookie: name=value" 到 req.Header —— 这会绕过标准 Cookie 生命周期管理，尤其在重定向时彻底失效：
- 必须用
net/http/cookiejar：创建jar, _ := cookiejar.New(&cookiejar.Options{PublicSuffixList: publicsuffix.List}) - 把 jar 赋给
http.Client.Jar：client := &http.Client{Jar: jar}，之后所有请求都自动收发 Cookie -
publicsuffix.List不能省：它提供 eTLD+1 规则（如example.co.uk→co.uk），防止跨域泄露；不传会导致Domain匹配失败 - 手动调用
jar.SetCookies()或jar.Cookies()是反模式，Client 已封装好逻辑，干预反而破坏重定向链中的 Cookie 流转
删除 Cookie 实际上是覆盖写入一个“已过期”的版本
没有真正的“删除”操作，浏览器只认 Set-Cookie 头里的过期信号：
- 最稳妥方式：复用原 Cookie 的
Name、Path、Domain（如果当初设过），然后设MaxAge: -1或Expires: time.Unix(0, 0) - 漏掉
Path或Domain会导致旧 Cookie 残留：浏览器按“完全匹配”规则清理，路径不一致就清不掉 - 前端 JS 调用
document.cookie = "name=; expires=Thu, 01 Jan 1970 00:00:00 GMT"也得同步带上path=/，否则只删当前路径下的 - HttpOnly Cookie 无法被 JS 删除，只能靠服务端下发过期指令
真正难的不是写几行 http.SetCookie，而是让每个 Cookie 字段的取值都经得起安全审计、每条重定向链里的 Cookie 都不丢失、每次读取后都做服务端存在性与完整性双重校验——这些细节一旦松动，会话管理就从便利变成漏洞入口。
