为什么 cookiejar 默认不生效？
因为 http.Client 初始化时不会自动关联 cookiejar，必须显式传入。不配就等于没用，所有响应里的 Set-Cookie 都被丢弃，后续请求也不会带 Cookie 头。
实操建议：
- 用
cookiejar.New创建实例，注意它接收一个cookiejar.Options，其中PublicSuffixList必须设置（否则初始化失败） - 推荐直接用
golang.org/x/net/publicsuffix提供的publicsuffix.List -
http.Client要通过CheckRedirect配合，否则重定向时 Cookie 不会自动带上（默认策略会丢掉）
jar, _ := cookiejar.New(&cookiejar.Options{PublicSuffixList: publicsuffix.List})
client := &http.Client{
Jar: jar,
CheckRedirect: func(req *http.Request, via []*http.Request) error {
return nil // 允许重定向，并让 jar 自动处理 Cookie
},
}
如何避免跨域名 Cookie 混乱？
cookiejar 默认按 RFC 6265 严格校验域名和路径，比如 example.com 的 Cookie 不会发给 api.example.com，除非原始 Set-Cookie 显式声明了 Domain=example.com。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 登录后访问子域接口返回 401 —— 因为 Cookie 没带上
- 抓取多个独立站点时互相污染（比如 A 站的
session_id错误发给了 B 站）
实操建议：
- 确认服务端
Set-Cookie的Domain字段是否合理；若控制不了服务端，可临时用自定义cookiejar实现宽松策略（但慎用） - 不同目标域名建议用独立的
cookiejar实例，避免复用同一个http.Client - 调试时打印
jar.Cookies(u)可直观看到当前 URL 能匹配哪些 Cookie
cookiejar 在并发请求下安全吗？
安全，但仅限于「读写隔离」：内部用了 sync.Mutex，所以多 goroutine 共享同一个 http.Client（即同一个 jar）不会 panic 或数据错乱。
不过要注意：
- Cookie 存储是全局的，A 请求 set 的 Cookie，B 请求可能立刻读到并发送——这在爬虫中常是预期行为，但若逻辑依赖「会话隔离」（如模拟多个用户），就必须拆分
jar实例 - 没有 TTL 自动清理机制，长期运行的爬虫需定期调用
jar.SetCookies手动清理过期项（或自己封装一层带时间检查的 wrapper） - 内存占用随 Cookie 数量线性增长，高频抓取大量域名时留意 GC 压力
替换 cookiejar 的轻量替代方案有哪些？
当只需要基础 Cookie 维护（比如只记一个 sessionid），或想绕过域名校验、避免引入 x/net 依赖时，手动管理更可控。
实操建议：
- 用
http.Header.Set("Cookie", "sessionid=xxx")手动拼接，适合固定 Cookie 场景 - 用
net/http.Cookie结构体 +req.AddCookie，比字符串拼接更安全（自动处理编码） - 若需自动提取
Set-Cookie，可用http.ReadSetCookies解析响应头，再存到 map 中按需注入
这类做法跳过了 cookiejar 的全部校验逻辑，也意味着你要自己处理过期、路径匹配、Secure/HttpOnly 标志等细节——简单场景够用，复杂交互容易漏。
真正麻烦的从来不是怎么存 Cookie，而是服务端怎么发：Domain 写错、Path 过窄、没设 Max-Age 导致会话级 Cookie 在客户端关掉就消失……这些才是 debug 时最耗时间的地方。
