http.CookieJar 管理跨请求会话 Cookie 的实现方式

Go 客户端要在多个请求之间维持 Cookie 会话，可以用 net/http/cookiejar.New 创建 Jar，再赋给同一个 http.Client.Jar。Client 会把响应中的 Cookie 交给 Jar，并在后续请求中选择符合目标 URL 的 Cookie；只创建 Jar 却没有绑定 Client，不会自动生效。

架构上应当先按会话身份隔离 Jar，再复用客户端和连接资源。一个账号或一个逻辑会话使用自己的 Jar，避免把多个用户的 Cookie 混进同一个容器。Jar 保存的是客户端 Cookie 状态，不会自动完成登录或替代服务端的会话校验。

Go CookieJar 官方地址：https://pkg.go.dev/net/http/cookiejar

先按会话身份划分客户端

设一个服务要代表多个已授权账号调用同一业务接口。不同账号可能使用相同名字的 session Cookie，因此隔离不能只靠 Cookie 名称。我的选择是让 会话 A 持有 Client A 与 Jar A，让 会话 B 持有 Client B 与 Jar B。

Transport 负责连接等底层资源，可供配置兼容的客户端共享；Cookie 状态归 Jar 管。Client 与 Transport 应在配置完成后复用，不在每次请求里重建。复用同一个 Transport 不会自动让两个独立 Jar 合并；但如果代码直接共享同一个 Jar，就主动共享了会话状态。

并发安全与身份隔离是不同约束。CookieJar 接口要求实现支持多 goroutine 并发调用，但这不代表并发执行两个登录流程就具有业务顺序保证。一个会话更新凭据或退出登录时，应由业务层协调在途请求，避免后返回的旧响应再次更新状态。

在内存 Jar 与手工请求头之间做选择

普通跨请求会话优先使用标准内存 Jar，减少手工复制头字段的工作。它不把 Set-Cookie 响应头当成可以原样放进 Cookie 请求头的文本；这两个字段承担不同职责。使用 Jar 后，示例不再手工添加同名 Cookie，以免形成双重状态来源。

创建 Jar 时配置 publicsuffix.List。官方 Options 文档说明，空的公共后缀表虽然可用于测试，但无法提供相应的域范围防护。依赖说明：https://pkg.go.dev/golang.org/x/net/publicsuffix。这项配置只约束 Cookie 域规则，不能替代目标接口授权和重定向策略。

把同一个 Jar 接到完整请求示例

下面的完整程序接收两个用户自有接口地址：一个初始化会话，一个消费该会话。两者须具有相同的 HTTPS 主机和端口。初始化请求在此简化为 GET；若实际登录协议需要 POST、CSRF 字段或其他认证步骤，应按服务端协议替换，不能仅把地址改成登录页就认为登录完成。

示例依赖 golang.org/x/net/publicsuffix。可在已有模块中添加该依赖，并按项目工具链要求选择、锁定版本；本文不指定未经项目确认的版本号。

# 在已有 Go 模块内添加公共后缀表依赖，按项目流程保留 go.mod 与 go.sum。
go get golang.org/x/net/publicsuffix

package main

import (
    "context"
    "fmt"
    "io"
    "net/http"
    "net/http/cookiejar"
    "net/url"
    "os"
    "time"

    "golang.org/x/net/publicsuffix"
)

// parseTarget 只接受用户自己的 HTTPS 接口，不接受 URL 内嵌凭据。
func parseTarget(raw string) (*url.URL, error) {
    u, err := url.Parse(raw)
    if err != nil {
        return nil, fmt.Errorf("解析地址失败")
    }
    if u.Scheme != "https" || u.Host == "" || u.User != nil || u.Fragment != "" {
        return nil, fmt.Errorf("需要无内嵌凭据和片段的 HTTPS 地址")
    }
    return u, nil
}

// fetch 接收响应即可由 Client 更新 Jar；正文在函数内读取并关闭。
func fetch(ctx context.Context, client *http.Client, target *url.URL) error {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, target.String(), nil)
    if err != nil {
        return fmt.Errorf("创建请求失败")
    }
    resp, err := client.Do(req)
    if err != nil {
        // 不直接输出可能包含查询串的请求错误，避免日志泄露会话信息。
        return fmt.Errorf("请求失败，请在受控诊断中检查网络与重定向策略")
    }
    defer resp.Body.Close()
    const bodyLimit = 1  bodyLimit {
        return fmt.Errorf("响应正文超过示例的 1 MiB 上限")
    }
    if resp.StatusCode = 300 {
        return fmt.Errorf("接口返回 HTTP %d", resp.StatusCode)
    }
    // 示例不打印响应正文或 Cookie，只记录状态码。
    fmt.Println("HTTP", resp.StatusCode)
    return nil
}

func run(args []string) error {
    if len(args) != 2 {
        return fmt.Errorf("用法: cookie-session 会话初始化地址 后续资源地址")
    }
    start, err := parseTarget(args[0])
    if err != nil { return err }
    target, err := parseTarget(args[1])
    if err != nil { return err }
    if start.Host != target.Host {
        return fmt.Errorf("示例要求两个地址具有相同主机和端口")
    }
    jar, err := cookiejar.New(&cookiejar.Options{
        // 使用公共后缀表约束站点设置 Cookie 的域范围。
        PublicSuffixList: publicsuffix.List,
    })
    if err != nil {
        return fmt.Errorf("创建 CookieJar 失败")
    }
    client := &http.Client{
        Jar: jar,
        Timeout: 10 * time.Second,
        CheckRedirect: func(req *http.Request, via []*http.Request) error {
            // 示例限制为同主机 HTTPS 跳转，不实现跨站单点登录。
            if len(via) >= 5 || req.URL.Scheme != "https" || req.URL.Host != start.Host {
                return fmt.Errorf("重定向超出本例约定")
            }
            return nil
        },
    }
    ctx, cancel := context.WithTimeout(context.Background(), 20*time.Second)
    defer cancel()
    // 首个接口必须由你控制并按其协议返回合法 Set-Cookie。
    if err := fetch(ctx, client, start); err != nil { return err }
    // 后续请求复用同一 Client 与 Jar，不手工拼接 Cookie 头。
    return fetch(ctx, client, target)
}

func main() {
    if err := run(os.Args[1:]); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

程序只输出状态码，不输出 Cookie 值和响应正文。2xx 只说明 HTTP 层满足示例的成功条件，不能证明业务登录成功；实际代码还应解析服务端明确约定的业务结果。Jar 的更新发生在 Client 处理响应时，读取 Body 不是“保存 Cookie”的按钮。

响应正文在 fetch 内完成读取并关闭，避免把多个响应的关闭操作堆积到外层函数结束。1 MiB 是示例自定上限；正文超过限制时关闭连接即可，不为了连接复用而无上限读取。完整读完并关闭通常有利于底层连接复用，但连接是否复用仍取决于实际传输条件。

CheckRedirect 的同主机策略是本例的业务限制。需要跨站单点登录的系统不能照搬该限制，也不能简单删除所有限制后默认信任跳转；应列出真实认证流程允许的目标与传输条件。Client 对每一次实际跟随的重定向都会咨询 Jar，相关接口定义见 https://pkg.go.dev/net/http#Client。

Cookie 没有带上时按作用域定位

“响应里看到了 Set-Cookie，下一次却没有带上”并不一定是 Jar 失效。先确认两次请求使用同一个 Jar，再比较设置响应对应的 URL 与后续目标 URL：主机、路径、传输方式和有效期都会影响选择。

jar.Cookies(targetURL) 返回面向该目标的可发送 Cookie，不是完整存储导出接口。它只反映请求要用的内容，不能用返回对象缺少 Domain、Expires 等属性推断服务端没有设置这些属性。要分析接收属性，可以在受控诊断中查看响应解析后的 Cookie 元数据，同时避免记录会话值。匹配实现来源：https://go.dev/src/net/http/cookiejar/jar.go。

不同路径可存在同名 Cookie，不要把 Jar.Cookies 的结果简单转成“名称对应单值”的 map 再补回请求，否则可能丢失必要项。若 Cookie 已按规则发送而服务端仍返回未认证，应继续检查服务端会话是否失效、请求是否属于正确账号，以及业务认证步骤是否真正完成。

给会话结束和部署重启留出处理位置

标准 cookiejar 是内存实现，进程重启后不会自动恢复 Jar。容器迁移、任务重试和多副本部署都应明确会话归属：是每次按协议重新建立，还是由业务管理具有保护措施的持久存储。不能把进程内对象当作跨实例会话数据库，也不要把 Cookie 明文写入文章示例或普通日志。

如果只需放弃当前本地会话，可以让后续工作使用新的 Client 与新的 Jar，并在没有在途使用后丢弃旧引用；不要并发修改正在服务请求的 Client.Jar 字段。清空本地状态也不等于撤销服务端会话，真正退出要按服务端注销协议处理。

落地时先确定一个身份对应一个 Jar，再把需要连续会话的请求交给稳定的 Client；接着明确超时、重定向与正文上限，最后安排登录更新、失效恢复和退出的业务顺序。本文代码是原创说明示例，未执行接口请求，不把状态码或图片当成真实运行证据。

常见问题

只创建 cookiejar.New，继续用 http.Get 可以吗？

不可以据此获得该 Jar 的管理。包级 http.Get 使用默认客户端；应把 Jar 赋给实际使用的 Client，并通过该对象发起请求。

CookieJar 会保存浏览器 localStorage 或运行登录页脚本吗？

不会。这里管理的是 HTTP 请求中的 Cookie，不执行网页脚本，也不等同于浏览器配置文件。需要脚本生成令牌的认证流程应按服务端支持的接口协议集成。

Cookie 被发送就说明会话有效吗？

不说明。客户端只是按作用域发送状态，服务端仍可因为过期、撤销或业务条件拒绝请求。应用应依据明确的服务端返回语义决定是否刷新或重新认证。