Go cookiejar.Jar.Cookies 为什么没有返回某个 Cookie

如果 jar.Cookies(u) 没有返回某个 Cookie，通常不是 Cookie 一定没有存进去，而是它不满足这个 u 对应请求的发送条件。Cookies 查询的是“当前 URL 可以带上的 Cookie”，不是 Jar 的全量调试接口。

排查时把问题固定成四个输入：scheme、host、path 和 Cookie 属性。先传入真实请求即将使用的 URL，再依次检查 Domain、Path 和 Secure；不要先把问题改成手工拼接 Cookie 请求头。

先确认你查询的 URL 是请求 URL

cookiejar.Jar 实现的是内存中的 HTTP CookieJar。Cookies 接收一个 *url.URL，根据这个 URL 判断哪些 Cookie 可以发送。官方文档还明确说明：当 URL 的 scheme 不是 http 或 https 时，返回空切片。

因此，下面两种写法查询的不是同一个范围：

package main

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

func main() {
    jar, _ := cookiejar.New(nil)

    // Cookies 必须接收真正的 HTTP 请求 URL，file 等 scheme 会直接得到空结果。
    httpURL, _ := url.Parse("https://api.example.test/account")
    fileURL, _ := url.Parse("file:///tmp/account")

    fmt.Println(len(jar.Cookies(httpURL))) // 可能有匹配项
    fmt.Println(len(jar.Cookies(fileURL))) // 0
}

实际代码中不要重新拼一个“看起来相同”的地址。把创建请求时使用的 URL 直接传给 jar.Cookies，还可以避免端口、host 大小写、路径和 scheme 在两处逐渐变得不一致。

host 和 Domain 不匹配时，Cookie 会被排除

第二个常见误区是把“曾经从某个地址收到 Cookie”理解成“所有同站地址都能读到它”。没有 Domain 属性的 Cookie 是 host-only Cookie，只匹配设置它的主机；带有合法 Domain 的 Cookie 才可能覆盖对应子域。

例如，假设 Cookie 是在 api.example.test 下设置的：

// 仅演示 Cookie 的属性与查询 URL 关系，不手工拼接请求头。
cookie := &http.Cookie{
    Name:  "session",
    Value: "abc",
    // Domain 为空时，它是 host-only Cookie，只属于设置它的 host。
}

setURL, _ := url.Parse("https://api.example.test/login")
jar.SetCookies(setURL, []*http.Cookie{cookie})

sameHost, _ := url.Parse("https://api.example.test/profile")
otherHost, _ := url.Parse("https://www.example.test/profile")

fmt.Println(jar.Cookies(sameHost))  // 可以匹配 session
fmt.Println(jar.Cookies(otherHost)) // host-only Cookie 不会匹配

如果业务确实需要让父域下的多个子域共享 Cookie，设置时必须使用符合规则的 Domain，并注意公共后缀限制。cookiejar.New 的 Options.PublicSuffixList 用于判断域归属；生产代码通常应使用官方文档推荐的公共后缀列表，而不是为了测试方便长期保留一个不安全的空实现。

Path 只覆盖它允许的请求路径

host 匹配后还要看 Path。Cookie 的 Path 不是“只要同一个域就全部可见”的标签，它决定哪些请求路径可以带上 Cookie。请求路径相同可以匹配；请求路径以 Cookie Path 为前缀时，还需要满足边界规则，例如 Cookie Path 是 /account，/account/profile 可以匹配，但 /accounting 不能仅因为字符串前缀相同就匹配。

// 通过不同接口路径对比 Cookie 的路径覆盖范围。
loginURL, _ := url.Parse("https://api.example.test/account/login")
jar.SetCookies(loginURL, []*http.Cookie{
    {Name: "account", Value: "1", Path: "/account"},
})

profileURL, _ := url.Parse("https://api.example.test/account/profile")
similarURL, _ := url.Parse("https://api.example.test/accounting/list")

fmt.Println(jar.Cookies(profileURL)) // Path=/account 可以覆盖
fmt.Println(jar.Cookies(similarURL)) // 不是合法的路径边界匹配

还有一个容易忽略的细节：如果设置 Cookie 时没有明确 Path，Jar 会根据设置它的 URL 生成默认路径。登录接口、静态资源接口和业务 API 使用不同路径时，最好把 Path 的意图写清楚，否则后续只换了接口地址，就可能出现“同域但读不到”的现象。

Secure Cookie 要用 HTTPS 查询

当 Cookie 带有 Secure 属性时，普通 HTTP 请求不会匹配它。这个判断发生在 Jar.Cookies 的筛选阶段，所以即使你确认 Cookie 曾经进入 Jar，用 http:// 查询也可能得到空结果。

// Secure Cookie 只用于 HTTPS 请求；localhost 有标准库定义的本地开发例外。
secureCookie := &http.Cookie{
    Name:   "secure-session",
    Value:  "xyz",
    Secure: true,
    Path:   "/",
}

httpsURL, _ := url.Parse("https://api.example.test/")
httpURL, _ := url.Parse("http://api.example.test/")
jar.SetCookies(httpsURL, []*http.Cookie{secureCookie})

fmt.Println(jar.Cookies(httpsURL)) // 可以匹配
fmt.Println(jar.Cookies(httpURL))  // Secure 条件不满足

本地调试时如果使用 localhost 或回环地址，不要把开发环境的特殊行为直接推广到真实域名；正式请求应让 scheme 与服务端实际部署方式保持一致。

用一个最小诊断函数固定排查入口

排查时可以把 URL 和返回结果放在同一个函数里，先确认“查询对象”没有错，再回到 Cookie 的设置位置检查属性：

func dumpCookies(jar http.CookieJar, rawURL string) error {
    u, err := url.Parse(rawURL)
    if err != nil {
        return fmt.Errorf("解析请求 URL 失败: %w", err)
    }

    // 只打印匹配后的名称和值，避免把诊断误认为 Jar 的全量存储导出。
    cookies := jar.Cookies(u)
    fmt.Printf("请求 URL=%s，匹配 Cookie 数=%d\\n", u.String(), len(cookies))
    for _, c := range cookies {
        fmt.Printf("  %s=%s\\n", c.Name, c.Value)
    }
    return nil
}

调用这个函数时，优先传入即将交给 http.NewRequest 的同一个 URL。若返回结果少于预期，可以按以下顺序定位：

1. scheme 是否为 http 或 https，并且是否满足 Secure。
2. host 是否与设置 Cookie 的 host 相同，或被合法 Domain 覆盖。
3. path 是否落在 Cookie 的 Path 范围内，特别注意相似前缀而非路径边界。
4. Cookie 是否已经过期，设置时的 URL 是否让它落在了意外的默认路径。

别把“返回为空”当成 CookieJar 丢数据

Jar.Cookies 的语义更像“为这个请求准备 Cookie 头”，而不是“查询 Jar 里有哪些 Cookie”。同一个 Jar 传入不同 URL，结果不同是正常行为；返回的 Cookie 也只保留适合发送的名称和值，不应据此推断 Domain、Path 等内部属性已经被完整导出。

真正修复问题的关键是让设置 Cookie 的 URL、请求 URL 和 Cookie 属性形成一致的范围。确认 scheme、host、Path、Secure 四项后，自动 Cookie 仍然缺失，才继续回到响应头解析或服务端设置逻辑排查。

相关问题

为什么 jar.Cookies 返回的 Cookie 看不到 Domain 和 Path？

因为 Cookies 返回的是准备发送的 *http.Cookie 列表，标准库实现只把名称、值和 quoted 状态放进返回对象。它不是内部条目的完整导出 API。

http 和 https 查询同一个 Jar 为什么结果不同？

最常见原因是某些 Cookie 设置了 Secure。HTTPS 满足条件，HTTP 不满足；此外两次查询的 host 和 path 也必须分别比较。

给 Cookie 设置 Domain 就一定能跨子域吗？

不一定。Domain 必须与设置它的 host 合法匹配，还会受到公共后缀规则约束；host-only Cookie 则不会自动扩展到兄弟子域。