Go cookiejar 没有公共后缀列表时为什么会错误共享 Cookie

Go 的 net/http/cookiejar 在没有公共后缀列表时，仍然可以正常创建并保存 Cookie，但它无法可靠判断一个 Domain 是否跨过了注册域边界。于是，来自 foo.co.uk 的服务端可能设置影响 bar.co.uk 的 Cookie，测试中的登录态就会比生产环境更“宽松”。解决方案是给 cookiejar.Options.PublicSuffixList 配置 golang.org/x/net/publicsuffix 提供的列表，并把同注册域、跨注册域两类场景都放入回归测试。

官方文档：https://pkg.go.dev/net/http/cookiejar#Options

问题根源：PublicSuffixList 决定可设置域

PublicSuffixList 不是用来决定 Cookie 是否过期的，它回答的是“这个域名的公共后缀是什么”。例如 foo.example.com 的公共后缀通常是 com，而 foo1.foo2.co.uk 的公共后缀是 co.uk。CookieJar 需要这条信息，才能判断服务端是否试图把 Cookie 写到一个不应由单个站点控制的边界上。

从空列表迁移到 publicsuffix.List

生产语义的客户端应显式注入列表。下面的示例只演示配置和检查路径；它没有把图中的判断当作浏览器截图或本机运行证据。

package main

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

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

func main() {
    // 使用公共后缀列表，让 CookieJar 识别 co.uk 等注册边界。
    jar, err := cookiejar.New(&cookiejar.Options{PublicSuffixList: publicsuffix.List})
    if err != nil {
        panic(err)
    }

    origin, _ := url.Parse("https://foo.co.uk/")
    target, _ := url.Parse("https://bar.co.uk/")
    // 这个 Domain 跨越 co.uk；配置列表后不应被当作可共享 Cookie。
    jar.SetCookies(origin, []*http.Cookie{{Name: "sid", Value: "demo", Domain: "co.uk", Path: "/"}})
    fmt.Println("bar.co.uk cookies:", jar.Cookies(target))
}

迁移时不要只把 nil 改成列表就结束。测试应至少包含一个同注册域场景，例如 api.example.com 与 www.example.com，以及一个跨注册域场景，例如 foo.co.uk 与 bar.co.uk。前者验证业务允许的共享仍然存在，后者验证边界没有被测试客户端放宽。

测试与回归清单

第一，确认列表实现满足并发使用要求，不要在每个请求中临时创建不同实现。第二，把 Domain 属性、Host-only Cookie、Secure、Path 分开断言，避免把“没有 Cookie”误判成公共后缀规则生效。第三，为 localhost、内网后缀和 IP 地址建立单独样例；公共后缀列表主要解决公网域名层级，不能替代内部命名约定。

如果测试必须模拟特殊后缀，可以实现一个只读的 PublicSuffixList，但要在测试命名中明确它是替身，并保留一组使用 publicsuffix.List 的真实边界回归。这样既能覆盖业务域名，又不会把空列表带来的跨域接受行为误当成生产规则。

常见问题

为什么空列表仍然能通过测试？ 因为它是合法配置，CookieJar 仍会处理 Cookie；问题在于域名边界判断变宽，不一定立刻报错。

只配置公共后缀列表就能防止所有 Cookie 泄漏吗？ 不能。它只解决可设置域的边界，Cookie 名称、Path、Secure、SameSite 和客户端复用策略仍需分别检查。