Go http.CookieJar 如何控制会话范围

Go 的 http.CookieJar 不是“把所有 Cookie 放进一个全局袋子”，而是一个按请求 URL 决定接收、保存和回传范围的接口。实际使用时，最稳妥的做法是给每个会话创建独立的 cookiejar.Jar，把它交给对应的 http.Client，再用域名、Path、协议和过期时间解释“为什么这次请求没有带 Cookie”。

先确定 CookieJar 真正负责的范围

net/http.CookieJar 的职责很小但很关键：响应到达后，客户端把 Cookie 交给 SetCookies；准备发送请求时，再用目标 url.URL 调用 Cookies。接口允许实现自行决定保存策略，因此它不等于浏览器，也不承诺把 Cookie 写入磁盘。

标准库提供的实现位于 net/http/cookiejar。它把 Cookie 按域名、路径等属性放在内存中，并且实现需要支持并发使用。这个设计适合登录态、短期爬取会话或同一客户端内的多次请求；如果要求重启后继续使用，就要额外设计安全的持久化层。

创建带公共后缀策略的 Jar

默认创建方式很短，但工程上更值得关注的是 PublicSuffixList。它用于判断服务器能否为某个域设置 Cookie。官方文档明确提醒，传入 nil 虽然合法，却不适合生产安全场景，因为可能放宽类似 foo.co.uk 为 bar.co.uk 设置 Cookie 的边界。

package main

import (
    "log"
    "net/http"
    "net/http/cookiejar"

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

func newSessionClient() (*http.Client, error) {
    // 公共后缀表限制跨注册域的 Cookie 接收范围。
    jar, err := cookiejar.New(&cookiejar.Options{
        PublicSuffixList: publicsuffix.List,
    })
    if err != nil {
        return nil, err
    }

    // Jar 只属于这个客户端，避免不同账号或租户共享会话。
    return &http.Client{Jar: jar}, nil
}

func main() {
    if _, err := newSessionClient(); err != nil {
        log.Fatal(err)
    }
}

这里的关键不是把 Jar 塞进客户端，而是明确它的所有权：一个登录身份、一个租户或一条隔离的采集会话对应一个 Client。不要把带登录态的 Jar 放在全局变量里，再让无关请求共用。

用域名、路径和协议判断 Cookie 是否会发送

排查时先不要只打印 Jar 里有没有 Cookie。标准实现会综合判断 host、Path 和 Secure：域名不匹配不发送，路径不匹配不发送，标记为 Secure 的 Cookie 通常不会随普通 HTTP 发出，已经过期的持久化 Cookie 也会被清理。没有显式 Path 时，Jar 会依据设置 Cookie 的 URL 推导默认路径。

可以用一个小函数把“存在”和“会发送”分开观察：

import (
    "log"
    "net/http"
    "net/url"
)

func showCookies(jar http.CookieJar, rawURL string) error {
    // 先解析目标 URL，Cookies 的判断依据就是这个地址。
    u, err := url.Parse(rawURL)
    if err != nil {
        return err
    }

    cookies := jar.Cookies(u)
    for _, cookie := range cookies {
        // 这里只打印名称和值，生产日志不要泄露真实会话值。
        log.Printf("send %s=%s to %s", cookie.Name, cookie.Value, u.Path)
    }
    return nil
}

示例中的 jar.Cookies(u) 只代表“按这个 URL 筛选后准备发送的 Cookie”。若目标是 https://api.example.com/api/orders，一个 Path=/admin 的 Cookie 即使仍在 Jar 里，也不会出现在返回集合中。

把 Jar 注入 http.Client 并排查常见空结果

把 Jar 注入 http.Client 后，正常的响应 Cookie 会由客户端交给 Jar，后续请求再自动取回。出现“登录后还是未登录”时，可以按下面的顺序缩小范围：

手工调用 SetCookies 适合测试或导入受控的初始 Cookie，但仍要传入正确的设置来源 URL。生产环境不要把 Cookie 值写入普通日志，也不要为了“让它生效”把所有 Cookie 改成根路径或关闭 Secure；那会破坏原本的会话边界。

相关问题

CookieJar 能不能跨多个 http.Client 共享？

接口层面可以，但共享意味着共享登录态和并发访问边界。除非这些请求明确属于同一会话，否则更建议每个身份或租户独立创建 Jar。

cookiejar.Jar 会把 Cookie 保存到文件吗？

不会。标准实现是内存存储；需要重启后恢复时，应单独设计加密、过期和域名隔离策略，不能直接把会话值当普通配置文件落盘。

为什么调用 Jar.Cookies 返回空切片？

常见原因是目标 URL 的 scheme、host 或 Path 不匹配，Cookie 已过期，或者 Cookie 带有 Secure 而当前请求是 HTTP。先用同一个 URL 逐项核对这些条件。