Go CookieJar 怎样管理跨请求会话状态

我第一次给 Go HTTP 客户端接登录态时，先把 Cookie 手动拼进请求头，结果一遇到刷新、重定向或多次请求，状态就散落在业务代码里。更稳妥的做法是把一个 CookieJar 交给同一个 http.Client：客户端从响应接收 Cookie，再按目标 URL 选择下一次请求应该带上的 Cookie。

官方资料：https://pkg.go.dev/net/http/cookiejar

这套机制只负责 HTTP Cookie 的存储与收发，不等于浏览器，也不会替你完成登录。登录接口、身份过期和业务重试仍然要由程序自己决定。

CookieJar 解决的不是登录，而是 Cookie 的收发管理

http.CookieJar 是一个接口，核心是 SetCookies 和 Cookies 两组能力：前者接收响应中的 Cookie，后者根据 URL 返回准备发送的 Cookie。标准库的 net/http/cookiejar 提供了内存实现 Jar，它遵循 RFC 6265 的 Cookie 规则。

真正决定是否能跨请求复用的，是多个请求是否使用同一个客户端。把 Jar 交给 Client.Jar 后，客户端会把相关 Cookie 放进出站请求，也会用入站响应中的 Cookie 更新 Jar；如果 Jar 为 nil，只有显式写到请求上的 Cookie 才会发送。

把 Jar 接到同一个 http.Client

最小代码只需要创建 Jar，再把它绑定到客户端。下面的代码没有假设登录接口的具体字段，只展示“第一次响应设置状态，下一次请求复用状态”的客户端边界。

package main

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

func newSessionClient() (*http.Client, error) {
    // nil 配置可以创建内存 Jar；生产环境应根据域名安全要求选择公共后缀策略。
    jar, err := cookiejar.New(nil)
    if err != nil {
        return nil, err
    }

    // 后续请求必须复用这个 Client，Jar 才能保存跨请求状态。
    return &http.Client{Jar: jar}, nil
}

func requestWithSession(client *http.Client, url string) (*http.Response, error) {
    // Client 会按 URL 注入匹配的 Cookie，并在响应返回后更新 Jar。
    req, err := http.NewRequest(http.MethodGet, url, nil)
    if err != nil {
        return nil, err
    }
    return client.Do(req)
}

调用方要保留返回的 client，不要在每个函数里重新执行 cookiejar.New。另外，成功拿到响应后仍要关闭 resp.Body；CookieJar 不会替你处理响应体生命周期。

跨请求复用时，真正共享的是客户端状态

登录请求收到 Set-Cookie 后，Jar 才有可供后续请求筛选的状态。下一个请求是否带 Cookie，不是“这个客户端登录过”一句话决定的，而是由 Cookie 的 Domain、Path、Secure 和过期条件与目标 URL 是否匹配决定。

func printCookies(client *http.Client, rawURL string) error {
    // 先解析 URL，读取 Jar 中对该地址可用的 Cookie。
    u, err := url.Parse(rawURL)
    if err != nil {
        return err
    }

    // 只观察名称和值，避免把完整 Cookie 内容写入普通日志。
    for _, c := range client.Jar.Cookies(u) {
        log.Printf("cookie name=%s", c.Name)
    }
    return nil
}

上面的片段需要额外导入 log 和 net/url。它只用于说明读取边界：如果客户端的 Jar 没有初始化，直接访问 client.Jar.Cookies 会触发空指针，因此实际项目应先保证客户端构造函数返回了非空 Jar。

并发复用和安全边界要提前定好

官方文档要求 CookieJar 的实现可以被多个 goroutine 并发使用，http.Client 也适合复用。不过“可以并发使用”不代表所有身份状态都应该共享：同一个客户端适合代表一个会话或一个服务账号；多租户、不同用户或不同权限范围应分开创建客户端和 Jar。

• 不要把登录 Cookie 写死在源码、日志或错误信息中；排查时只记录 Cookie 名称和匹配结果。
• 需要精细控制域名策略时，配置 cookiejar.Options.PublicSuffixList；文档说明，空配置便于测试，但不适合作为安全策略。
• 请求 URL 改变后，Cookie 可能因 Domain、Path、Secure 或过期时间不匹配而不再发送，这不是 Jar 丢失状态。
• 服务端返回 401 后，应由业务层决定重新登录、清理 Jar 还是停止请求，不能把 Jar 当成永久凭证。

如果只需要一次性调用，手动设置单个请求 Cookie 反而更直观；只要请求链需要保存服务端状态，就让同一个 http.Client 持有 Jar，并把“客户端生命周期”和“用户身份生命周期”一起设计清楚。

常见疑问

CookieJar 会自动完成登录吗？

不会。它只保存和筛选 Cookie，登录请求的参数、验证码、刷新策略与业务权限仍由应用负责。

为什么 Jar 里有 Cookie，下一次请求却没有？

优先检查请求 URL 的协议、域名、路径和 Cookie 的过期属性，再确认请求使用的是创建 Jar 的同一个 http.Client。