go的http.client默认不保存cookie，必须显式配置cookiejar.new()并赋值给client.jar字段，否则登录态丢失、重定向时cookie不携带；推荐传入含publicsuffixlist的options以正确处理子域名匹配。
为什么不能直接用 http.Client{} 而要配 cookiejar
Go 的 http.Client 默认不保存任何 Cookie，每次请求都是“干净”的。即使服务器在响应头里返回了 Set-Cookie，不手动解析、存储、再塞回去，下一次请求就完全不会携带它——登录态、会话、CSRF token 全都断掉。
常见错误现象包括：登录接口返回 200 并带了 Set-Cookie: sessionid=abc，但紧接着访问 /profile 却返回 401；或者重定向（302）后 Cookie 消失，导致跳转到登录页。
-
cookiejar是标准库中唯一符合 RFC 6265 的自动管理实现，处理域匹配、路径匹配、过期、HttpOnly、SameSite等细节 - 不配
Jar字段的http.Client在重定向时完全忽略Set-Cookie，也不会回填 - 自己用 map 存 Cookie 手动加
Cookie头，会漏掉子域继承、MaxAge=0清理、Secure 限制等逻辑，容易出安全或兼容性问题
创建 cookiejar 必须传 publicsuffix.List 吗
不是必须，但强烈建议传。不传会导致子域名 Cookie 匹配错误，比如 api.example.com 设置的 Cookie 被 www.example.com 错误读取，违反同源策略。
cookiejar.New 接收一个 *cookiejar.Options，其中 PublicSuffixList 字段应设为 publicsuffix.List（来自 golang.org/x/net/publicsuffix）。这是 Go 官方推荐做法，也是企业级应用的底线配置。
- 若传
nil，jar 会退化为简单字符串前缀匹配，.example.com和example.com视为不同域 - 导入需额外加：
import "golang.org/x/net/publicsuffix" - 正确初始化示例：
jar, err := cookiejar.New(&cookiejar.Options{PublicSuffixList: publicsuffix.List})
如何让 cookiejar 在重定向中自动生效
只需把 jar 赋给 http.Client.Jar，后续所有请求（含自动跟随的 301/302/307）都会由 jar 自动注入 Cookie。不需要改请求逻辑、也不需要手动调 req.AddCookie。
关键点在于：jar 的生命周期必须长于 client，且 client 要启用重定向（默认已开启）。
-
http.Client默认CheckRedirect是非 nil 函数，会自动跳转；只要Jar非 nil，跳转请求就会自动带上匹配的 Cookie - 不要自己实现
CheckRedirect并忽略req.Header.Set("Cookie", ...)—— 这绕过了 jar，等于白配 - 如果禁用了重定向（
CheckRedirect: func(...){ return http.ErrUseLastResponse }），jar 仍会存 Cookie，但不会用于后续跳转请求
怎么验证 cookiejar 是否真的在工作
最直接的方式是检查 jar 内部状态，而不是只看响应状态码。因为即使没 Cookie，有些接口也可能返回 200（比如未登录时返回首页）。
用 jar.Cookies(u) 可以查当前 URL 匹配的 Cookie 列表，配合调试日志能快速定位问题。
- 先构造目标 URL：
u, _ := url.Parse("https://example.com/profile") - 再查：
cookies := jar.Cookies(u)，打印len(cookies)和每个cookie.Name - 注意：
jar.Cookies返回的是只读副本，修改它不影响 jar 内部状态 - 如果返回空切片，说明 jar 没存到任何匹配该 URL 的 Cookie —— 可能是 Set-Cookie 域/路径不匹配，或 jar 初始化时没传
PublicSuffixList
SameSite=Lax 对重定向的影响、Secure Cookie 在 HTTP 地址下的静默丢弃——这些细节藏在 jar 的 match logic 里，不验证就以为“配好了”，往往线上才暴露。
