Go net/http Cookie.DomainMatches 怎样判断域名是否匹配

先给结论：net/http 当前没有公开的 Cookie.DomainMatches 方法。http.Cookie 负责表示和序列化 Cookie，真正决定 Cookie 是否会随目标请求发送的是 net/http/cookiejar 内部的域名、路径和 Secure 规则。若要判断“这个 Cookie 会不会发给这个 URL”，优先让 CookieJar 做一次真实的匹配；只有在单元测试或策略预检中，才值得单独写纯函数。

我第一次遇到这个问题时，直觉是给 http.Cookie 找一个 DomainMatches 方法，结果发现 API 边界比标题想象得更重要：不存在的方法不能靠改包名或猜内部函数来调用。

先分清 http.Cookie 与 CookieJar 的职责

http.Cookie 只有 Domain 字段，它能把 Cookie 编码为请求或响应头，但不对外承诺一个域名匹配方法。官方实现把 Cookie 的实际发送判断放在 net/http/cookiejar，其中还会把 HostOnly、路径和 Secure 条件一起考虑。

因此，下面三种写法的定位不同：

想看真实发送结果，就让 CookieJar 判断

如果问题是“设置在 example.com 的 Cookie，会不会发送给 api.example.com”，不要只调用字符串后缀判断。把 Cookie 放入 Jar，再向目标 URL 查询，得到的结果更接近客户端真正使用的行为：

package main

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

func main() {
    // CookieJar 负责保存 Cookie，并按目标 URL 决定是否返回它。
    jar, err := cookiejar.New(nil)
    if err != nil {
        panic(err)
    }

    // 用响应来源 URL 写入 Cookie；Domain 由 Cookie 本身声明。
    origin, _ := url.Parse("https://example.com/login")
    jar.SetCookies(origin, []*http.Cookie{{
        Name:   "session",
        Value:  "demo",
        Domain: "example.com",
        Path:   "/",
    }})

    // 查询目标请求会携带哪些 Cookie，避免猜测内部匹配函数。
    target, _ := url.Parse("https://api.example.com/data")
    cookies := jar.Cookies(target)
    fmt.Println(len(cookies), cookies[0].Name)
}

这个判断回答的是“实际客户端行为”：目标主机是 api.example.com 时，域名 Cookie 可以沿着点号分隔的子域匹配；如果目标是 example.com.evil.test，不能因为字符串包含 example.com 就算匹配。

需要纯函数时，至少保留点号边界

有些代码只想在发请求前做快速策略判断，例如限制某个跳转目标是否仍属于允许的 Cookie 域。这时可以写一个小函数，但要明确它是业务预检，不是对 CookieJar 全部语义的替代。最容易出错的是直接使用 strings.HasSuffix(host, domain)：它会把 notexample.com 错当成 example.com 的子域。

package cookiecheck

import "strings"

// domainMatches 只做域名边界预检，不负责路径、Secure 或过期时间判断。
func domainMatches(cookieDomain, host string, hostOnly bool) bool {
    cookieDomain = strings.TrimPrefix(strings.ToLower(cookieDomain), ".")
    host = strings.ToLower(host)

    // 空值不能形成可靠的域名判断，直接拒绝更安全。
    if cookieDomain == "" || host == "" {
        return false
    }
    // HostOnly Cookie 只允许原主机，不能扩展到子域。
    if hostOnly {
        return host == cookieDomain
    }
    // 精确匹配是最常见且最明确的情况。
    if host == cookieDomain {
        return true
    }
    // 子域必须以点分隔，不能只依赖裸 HasSuffix。
    return strings.HasSuffix(host, "."+cookieDomain)
}

这个纯函数仍然有边界：它没有处理 IP 地址、规范化后的端口、Cookie 路径、Secure、过期时间和公共后缀策略。若业务要求与 HTTP 客户端完全一致，应该回到 CookieJar；若只是做明确的允许域策略，才使用这种收窄后的判断。

按场景选择，避免把预检当成完整实现

我的取舍是：需要知道请求实际携带什么，就选 CookieJar；需要在配置加载阶段快速拒绝明显不允许的域名，就选带测试用例的纯函数；如果需求只是“Cookie 必须只回到同一主机”，直接使用 HostOnly 思路，不要额外扩大到子域。

排查时可以按这张清单走：

• 先确认代码里没有把不存在的 http.Cookie.DomainMatches 当成公开 API。
• 再确认 Cookie 是通过哪个来源 URL 写入 Jar 的。
• 检查目标 URL 的主机、路径、协议，以及 Cookie 的 Domain、Path、Secure 和过期状态。
• 只有在规则明确、范围收窄时，才使用自定义函数；并为精确域名、合法子域和相似域名各写一个测试。

相关问题

为什么 strings.HasSuffix 不够？ 因为它不检查域名标签边界，可能把拼接出来的相似主机误判为子域。

CookieJar 能不能只判断域名？ 它会综合域名、路径、Secure 和 Cookie 状态；如果你只关心域名，使用纯函数更直观，但要明确它不是完整发送判断。

Domain 为空怎么办？ 不要把空值当成任意域名。让 Jar 根据来源 URL 管理 HostOnly 语义，业务预检则直接拒绝空域名输入。