Go CookieJar 为什么没有保存服务端返回的 Cookie

不少用 Go 做请求模拟、自动登录或者爬虫的开发者，都碰到过明明看到服务端响应里明确返回了 Set-Cookie 头，预先初始化好的 CookieJar 里却始终找不到对应Cookie的情况，排查起来完全摸不着头脑。

net/http 标准库内置的 CookieJar 默认严格遵循 RFC 6265 规范做校验过滤，只有 Cookie 的 Domain、Path、Secure 等属性完全匹配当前请求上下文时才会被正式存入，不符合规则的Cookie会被直接静默丢弃，不会主动抛出报错提示。

Go 里的 CookieJar 没有保存服务端返回的 Cookie，通常不是响应头凭空消失，而是客户端没有配置 Jar，或者 Cookie 的作用域与下一次请求的 URL 对不上。先检查 http.Client.Jar 是否指向同一个 cookiejar.Jar，再对照 Set-Cookie 里的域名、路径、Secure 和过期时间。

最小修复是为客户端创建一个持久于本次进程内存的 Jar，并在同一个 Client 上复用它；如果 Jar 中仍然为空，就用当前请求 URL 调用 jar.Cookies(u)，逐项排查匹配条件。

先确认 Client 真的配置了 Jar

http.Response.Cookies() 只能告诉你这一次响应声明了哪些 Cookie；自动保存和下一次请求回带，依赖的是 http.Client.Jar。如果直接调用 http.Get，实际使用的默认 Client 通常没有 Jar，所以看到了 Set-Cookie，下一次请求却没有 Cookie 头。

package main

import (
    "fmt"
    "net/http"
    "net/http/cookiejar"
    "net/url"
)

func main() {
    // Jar 只保存在当前进程内，后续请求必须复用同一个 Client。
    jar, err := cookiejar.New(nil)
    if err != nil {
        panic(err)
    }
    client := &http.Client{Jar: jar}

    u, err := url.Parse("https://api.example.com/account")
    if err != nil {
        panic(err)
    }
    // 这里能看到当前 URL 经过 Jar 规则筛选后的 Cookie。
    fmt.Println(client.Jar.Cookies(u))
}

生产环境的跨子域场景应给 cookiejar.New 配置公开后缀列表，例如 publicsuffix.List。官方文档明确指出，空的 PublicSuffixList 适合测试但不安全，因为它可能放宽不同注册域之间的 Cookie 设置边界。

把响应声明和 Jar 内容分开看

排查时不要只打印响应头，也不要只看业务请求是否成功。先记录 resp.Cookies()，确认服务端确实返回了目标 Cookie；然后把响应 URL 解析成 *url.URL，调用 jar.Cookies(u)。前者是“服务端声明”，后者是“客户端按规则愿意带回的结果”，两者不相等并不一定是 Go 丢数据。

// 只打印诊断信息，不把 Cookie 值写入生产日志。
for _, c := range resp.Cookies() {
    fmt.Printf("Set-Cookie: name=%s domain=%s path=%s secure=%t maxAge=%d\n",
        c.Name, c.Domain, c.Path, c.Secure, c.MaxAge)
}

// u 应该是下一次真实请求的 URL，而不是随手拼出的首页地址。
nextURL, err := url.Parse("https://api.example.com/account/profile")
if err != nil {
    return err
}
for _, c := range jar.Cookies(nextURL) {
    fmt.Printf("Jar cookie: %s\n", c.Name)
}

按 URL 匹配规则排查 Cookie 为什么消失

下面这张表适合逐项排查。Cookie 被保存后，访问不同 URL 时也可能因为条件变化而暂时“看不见”。

还要留意 URL 的 scheme。官方 cookiejar.Jar.SetCookies 对非 HTTP/HTTPS URL 不做处理，Cookies 也会返回空结果。另一个容易忽略的边界是公共后缀：服务端不能随意把 Cookie 设到不属于自己的公共后缀上，客户端使用 PublicSuffixList 能帮助 Jar 拒绝这类不合理声明。

把修复固化成回归检查

修复后至少覆盖四种请求：同一主机同一路径、同一主机不同路径、HTTP 与 HTTPS 切换、重定向后的最终 URL。每次都在请求发出前用 jar.Cookies(nextURL) 检查预期名称，而不是把完整 Cookie 值写进日志。

如果业务需要跨重启保留登录状态，标准 cookiejar.Jar 本身不是磁盘数据库。应明确保存哪些字段、如何加密、何时过期和如何避免把会话凭据写入普通日志；不要用“把 Jar 指针放进全局变量”代替持久化设计。

相关问题

为什么能从 resp.Cookies() 看到 Cookie，下一次请求却没有？

因为前者只读取响应声明，后者还要经过 Client 的 Jar 和 URL 匹配规则。先确认 Client.Jar 非空，再检查下一次请求的域名、路径和 scheme。

每次调用 cookiejar.New 会发生什么？

会得到一个新的空内存 Jar。若每次请求前都新建，前一次响应留下的会话自然无法被下一次请求使用。

CookieJar 能跨程序重启保存 Cookie 吗？

不能直接做到。它是内存实现，跨重启需要自行持久化，并同时处理敏感信息保护、过期和恢复失败。

为什么 cookiejar.New(nil) 能运行却不适合生产？

nil 选项是合法的，但没有公共后缀列表时，跨域限制会变宽。测试可以使用它，生产跨子域场景应配置可信的 PublicSuffixList。