Go http.CookieJar区分 Domain 与 HostOnly Cookie的边界说明

Go 的 http.CookieJar 不会把所有 Cookie 按字符串简单地塞进一个全局表。对同一个 Cookie 名称，Domain 是否为空会直接影响它的主机边界：没有显式 Domain 的 Cookie 通常是 HostOnly，只回到设置它的主机；带有合法 Domain 的 Cookie 才可能匹配该域及其子域。判断时还要同时看 Path、Secure、请求协议和公共后缀限制。

排查 Go Cookie 作用域时，先区分 HostOnly 与 Domain，再用 Jar.Cookies(u) 针对具体 URL 查看是否匹配；不要只看 Cookie 的 Name 和 Value。

Domain 为空时，CookieJar 如何形成 HostOnly 边界

服务端通过 Set-Cookie 返回 Cookie 时，如果没有写 Domain，它只绑定设置它的主机。例如响应来自 api.example.com，不会仅因共享后缀就自动发送给 example.com 或 img.example.com。显式写入 Domain=example.com 后，候选范围才可能扩大到符合规则的子域，但仍不是全局变量。

// 这个示例只展示两种作用域的声明方式，不代表在本机执行后的真实输出。
hostOnly := &http.Cookie{
	Name:  "session",
	Value: "host-value",
	Path:  "/",
}

domainCookie := &http.Cookie{
	Name:   "session",
	Value:  "domain-value",
	Domain: "example.com", // 允许符合规则的子域参与匹配
	Path:   "/",
}

_ = hostOnly
_ = domainCookie

显式 Domain 为什么只能扩大到符合规则的子域

判断 Cookie 是否会出现在请求里，入口是目标 URL。Jar.Cookies(u) 会依据 scheme、主机和路径筛选；Secure 与 Path 也会继续收窄范围。

// 用目标 URL 查询 Jar，重点是观察域名和路径边界。
jar, err := cookiejar.New(&cookiejar.Options{
	PublicSuffixList: publicsuffix.List, // 生产环境启用公共后缀保护
})
if err != nil {
	log.Fatal(err) // 初始化失败时不要继续使用空 Jar
}

origin, _ := url.Parse("https://api.example.com/login") // Cookie 的设置主机
jar.SetCookies(origin, []*http.Cookie{{
	Name: "session", Value: "abc", Path: "/account",
}})

target, _ := url.Parse("https://api.example.com/account/profile") // 满足主机和路径
cookies := jar.Cookies(target) // 结果只说明 target 是否满足匹配条件
log.Printf("matched cookies: %d", len(cookies))

上例的 Cookie 没有 Domain，因此把 target 换成 img.example.com/account/profile 后，即使路径相同，也不应把它当成可用凭据。若要让子域参与匹配，应由服务端明确设置合法 Domain，并接受更宽作用域的风险。

PublicSuffixList 是 Domain 边界之外的第二道约束

只检查字符串后缀还不够。co.uk、com 这类公共后缀不是单个业务站点可以随意接管的范围。cookiejar.Options.PublicSuffixList 用来判断 HTTP 服务端是否能为某个域设置 Cookie。官方文档明确指出，传入 nil 便于测试，但不安全，可能允许一个站点为同一公共后缀下的另一站点设置 Cookie。

因此生产代码更适合传入 golang.org/x/net/publicsuffix 提供的 publicsuffix.List。这不是用来改变 HostOnly 与 Domain 的含义，而是防止 Domain Cookie 越过公共后缀的站点边界。测试需要构造特殊域名时，可以使用 nil，但应把这个选择限制在测试范围内。

Cookie 没被投递时，按这张表逐项排查

调试时固定一个 URL，记录 scheme、Hostname 和 Path，再调用 jar.Cookies(u)。先确定服务端的 Set-Cookie 声明，再判断问题属于 HostOnly、域匹配、路径还是安全属性。

相关问题

HostOnly Cookie 能否直接发送给父域？

不能。HostOnly 的核心就是绑定设置它的主机；需要覆盖父域及子域时，应由服务端明确设置合法 Domain，并重新评估凭据暴露范围。

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

除了作用域不匹配，还可能是 URL 不是 HTTP/HTTPS、Path 不匹配，或 Secure Cookie 被用于不满足条件的请求。应按请求 URL 逐项检查。

cookiejar.New(nil) 能用于生产吗？

它可以创建 Jar，但公共后缀保护不完整。生产客户端应配置 publicsuffix.List；nil 更适合受控测试。

一句话记忆：Domain 为空看原始主机，Domain 有值看域匹配，最后再叠加 Path、Secure、scheme 和 PublicSuffixList。

Domain 与 HostOnly Cookie 的静态匹配边界