r.cookie("name") 必须先检查 err == http.errnocookie 再处理其他错误，不能仅判断 cookie == nil；设置 cookie 时需设 httponly、secure、samesite、maxage/expires 和 path 才安全。
怎么用 r.Cookie() 安全读取客户端 Cookie
Go 里读 Cookie 不是“有没有”，而是“有没有读对”——r.Cookie("name") 返回的是 *http.Cookie 和一个 error，必须显式判断错误类型，不能只看值是否为空。
- 常见错误：直接
if cookie == nil判断，但r.Cookie()在没找到时返回nil, http.ErrNoCookie，不是nil, nil - 正确做法：先检查
err == http.ErrNoCookie，再处理其他 error（比如解析失败） - 注意：该方法只匹配
Name，不校验Path、Domain或SameSite，这些由浏览器在发送请求时自动过滤，服务端无需、也不能验证
http.SetCookie() 必须设哪些字段才不算裸奔
只写 Name 和 Value 就调用 http.SetCookie()，等于把 session token 贴在 HTTP 明文里发给浏览器——开发环境可能跑得通，上线后大概率被扫、被窃、被伪造。
-
HttpOnly: true：禁用document.cookie访问，防基础 XSS 泄露 -
Secure: true：强制仅 HTTPS 传输（本地调试可设false，但部署前必须改回来） -
SameSite: http.SameSiteStrictMode或http.SameSiteLaxMode：防 CSRF，推荐 Lax（兼顾兼容性与安全性） -
MaxAge或Expires二选一：不设 = 会话级 Cookie（关浏览器就丢），设了才持久；MaxAge: 0表示立即过期（常用于登出） -
Path: "/"：显式设，避免因路由路径不匹配导致 Cookie 不下发
为什么 req.AddCookie() 不能用来“设置” Cookie
这是新手高频误用点：http.Request.AddCookie() 是往 *当前请求* 的 Cookie 列表里加一条记录，它只影响你后续怎么读这个 r.Cookies()，**完全不会触发 Set-Cookie 响应头**。
- 现象：调了
req.AddCookie(&c)，但浏览器开发者工具里看不到新 Cookie，刷新也没用 - 原因：服务器响应没带
Set-Cookie:头，浏览器根本不知道要存什么 - 正解：必须用
http.SetCookie(w, &cookie)，且w是http.ResponseWriter，不是Request - 例外场景：仅在测试中模拟带 Cookie 的请求（比如用
httptest.NewRequest()），此时AddCookie才有意义
重定向时 Cookie 丢了？大概率没配 cookiejar
如果你在 Go 客户端代码里发起登录请求，收到 Set-Cookie，但紧接着的重定向请求里 Cookie 消失了，不是服务端问题，是你客户端没启用 Cookie 自动管理。
- 默认
http.Client{}的Jar字段是nil，所有 Cookie 都被丢弃 - 必须显式创建并赋值：
client.Jar, _ = cookiejar.New(nil)（net/http/cookiejar包提供） - 不用自己实现
CookieJar接口——RFC 6265 规则太复杂（Domain 匹配、Path 继承、Secure 协议推导等），标准库cookiejar已覆盖全部边界 - 注意：
cookiejar.New(nil)中的nil是配置参数，不是错误；如需自定义策略（比如允许特定子域名），才传非 nil 的&cookiejar.Options
Cookie 看似简单，但每个字段背后都是浏览器和 RFC 的隐式契约。少设一个 HttpOnly，XSS 就可能拿到 token；漏掉 SameSite，CSRF 攻击就少一道屏障；客户端不配 cookiejar，重定向就等于重新登录——这些都不是“以后优化”的事，是上线前必须对齐的底线。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
