Go net/http CookieJar 怎么让客户端自动维护会话

Go 的 http.Client 默认没有替你保存跨请求 Cookie。要让客户端自动维护会话，关键是创建 net/http/cookiejar 的 Jar，把它放进 http.Client{Jar: jar}，然后复用同一个 Client 完成登录和后续请求。登录响应里的 Set-Cookie 会被 Jar 接收；后续 URL 满足域名、路径和安全属性时，Client 会自动把 Cookie 带回。

先把 CookieJar 放到正确的位置

http.CookieJar 是一个接口，负责针对某个 URL 接收响应 Cookie，并返回下一次请求应发送的 Cookie。标准库的 net/http/cookiejar 提供了内存实现。它不是一个单独的请求参数，而是 http.Client 的会话存储。

下面这个结构就是最小可用关系：同一个 Client 持有 Jar，同一个 Jar 负责登录响应和后续请求之间的状态传递。这里没有手工拼接 Cookie 请求头，也没有把登录返回的值复制到全局变量。

用 cookiejar.New 创建可复用的客户端

创建 Jar 时传入 nil 选项即可使用默认策略。创建失败要立即返回，不要让一个没有 Jar 的 Client 继续跑到登录流程里。示例中的 loginURL 和 profileURL 只是同一服务的两个接口，真实项目中按自己的地址替换。

package main

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

func newSessionClient() (*http.Client, error) {
    // Jar 保存当前客户端收到的 Cookie，并按 URL 规则决定是否带回。
    jar, err := cookiejar.New(nil)
    if err != nil {
        return nil, fmt.Errorf("create cookie jar: %w", err)
    }

    // 登录与业务请求必须复用这个 Client，不能每次请求都重新创建。
    return &http.Client{Jar: jar}, nil
}

func main() {
    client, err := newSessionClient()
    if err != nil {
        panic(err)
    }

    loginURL := "https://api.example.com/login"
    profileURL := "https://api.example.com/profile"

    // 真实项目中这里应使用带超时、请求体和错误处理的登录请求。
    loginResp, err := client.Get(loginURL)
    if err != nil {
        panic(err)
    }
    loginResp.Body.Close()

    // 同一个 Client 会根据 profileURL 自动选择应发送的 Cookie。
    profileResp, err := client.Get(profileURL)
    if err != nil {
        panic(err)
    }
    defer profileResp.Body.Close()
    fmt.Println(profileResp.Status)

    // 只为演示如何查看当前 URL 可匹配到的 Cookie；不要手工拼请求头。
    u, _ := url.Parse(profileURL)
    fmt.Println(client.Jar.Cookies(u))
}

示例故意没有把 Cookie 写到 Authorization 或自定义请求头中。Cookie 的发送由 Jar 根据 URL 和 Cookie 属性决定，这比在业务代码里维护一份字符串更不容易串会话。

登录响应怎样进入后续请求

关键动作发生在 Client 的传输过程中：响应头包含 Set-Cookie 时，Client 会把它交给 Jar；下一次请求创建或发送前，Jar 再根据目标 URL 返回可用 Cookie。代码层面只需要保持 Client 不变。

如果你想显式验证状态，可以从 Jar 读取某个 URL 的 Cookie，而不是直接访问 Jar 的内部字段：

func cookiesFor(client *http.Client, rawURL string) ([]*http.Cookie, error) {
    // 解析 URL 失败时直接返回，避免把 Cookie 绑定到错误的主机。
    u, err := url.Parse(rawURL)
    if err != nil {
        return nil, fmt.Errorf("parse request URL: %w", err)
    }

    // Cookies 只返回这个目标 URL 当前应携带的 Cookie。
    return client.Jar.Cookies(u), nil
}

注意，client.Jar 可能为 nil。生产代码在读取它前应先确认 Client 是通过统一构造函数创建的；如果允许外部传入 Client，则先判断 client == nil、client.Jar == nil，再决定是拒绝配置还是使用独立的 Cookie 方案。

域名、路径和进程生命周期决定会话边界

CookieJar 并不是“收到 Cookie 就对所有请求发送”。Cookie 的域名、Path、Secure 等属性仍然影响匹配；例如登录接口返回的 Cookie 只允许发往特定路径，换到不匹配的子域或非 HTTPS 地址时，Jar 可能不会返回它。CookieJar 还只处理 HTTP 和 HTTPS URL，其他 scheme 不应期待它自动带 Cookie。

标准 Jar 适合单进程里的短期会话。如果要跨重启恢复，不能直接假设 cookiejar.New 会写磁盘；应明确设计序列化格式、权限和过期策略。若服务端要求登录态不能长期保存，也不要为了“自动登录”无限延长 Cookie 生命周期。

并发使用时保留一个 Jar，切账号时换一个 Jar

官方接口要求 CookieJar 的实现支持多个 goroutine 并发使用，因此一个会话 Client 可以被并发请求复用。但“支持并发”不等于“所有账号共用状态”：多账号场景应为每个账号创建独立的 Jar 和 Client，避免同一进程内出现 Cookie 交叉。

还要注意响应体关闭、请求超时和客户端生命周期。CookieJar 只负责 Cookie 状态，不负责超时、重试、连接池治理或业务鉴权；这些配置仍应在 http.Client、Transport 和调用方中单独处理。

常见问题

为什么我给每次请求都 new 一个 http.Client，登录态还是丢了？

因为每次创建的新 Client 没有复用原来的 Jar。把带 Jar 的 Client 作为依赖传入业务函数，或者按账号维护 Client 生命周期。

能不能直接读取 Jar 里的全部 Cookie？

http.CookieJar 只保证按 URL 获取 Cookie 的接口，不保证提供全量遍历能力。需要检查某次请求时，调用 client.Jar.Cookies(targetURL) 更符合它的抽象。

CookieJar 能替我保存跨进程会话吗？

不能把标准内存 Jar 当作跨进程存储。跨进程或重启恢复需要单独的持久化设计，同时评估敏感 Cookie 的加密、权限、过期和注销策略。

可继续查阅 Go net/http 官方文档中的 CookieJar 接口，以及 net/http/cookiejar 官方文档中的 Jar 实现说明。把 Client、Jar 和账号边界设计清楚后，Go 客户端就能在不手工拼 Cookie 的情况下稳定维护会话。