Go HTTP Cookie 的 Path 和 Domain 怎样影响发送范围

我在排查 Go HTTP 会话时，最容易误判的一点就是：Cookie 已经设置成功，为什么下一次请求却没有带上？通常不是 Cookie 名称的问题，而是请求 URL 没有同时满足它的主机范围和路径范围。Go 的 http.Cookie 只描述这些属性，真正按 URL 筛选并发送 Cookie 的客户端通常是 cookiejar。

官方资料：https://pkg.go.dev/net/http#Cookie

可以把范围记成两个条件：Domain 决定“发给哪个主机”，Path 决定“发给这个主机下哪些路径”。省略 Domain 时通常是 host-only；Path 也不是任意字符串前缀，而是带目录边界的匹配。

• http.SetCookie 负责把 Cookie 写入响应的 Set-Cookie 头。
• 带 Jar 的 http.Client 才会根据后续请求 URL 自动选择 Cookie。
• Path=/app 可以覆盖 /app/report，但不能因为字符串前缀关系就覆盖 /apple。
• 显式 Domain=example.com 可以覆盖该域及其子域；省略它则不应按子域共享来设计。

先分清 Cookie 是在哪里被筛选的

服务端调用 http.SetCookie 时，Go 只是根据 Cookie 结构体生成响应头。浏览器或 Go 客户端收到这个头后，才会把名称、值、Path、Domain 等属性保存起来。之后，客户端生成请求时再判断当前 URL 是否匹配。

这也是我排查“服务端明明设置了 Cookie”时的第一个分界点：如果客户端没有 Jar，http.Client 不会凭空保存响应 Cookie；如果有 Jar，也不能只看 Cookie 名称，要继续看请求的 scheme、主机和路径。

Path 为什么会让相邻路径表现不同

Path 的直觉可以从目录关系理解。Cookie 的 Path 是 /app 时，/app 和 /app/report 属于匹配范围；但 /apple 只是字符开头相同，缺少目录分隔边界，不能按“所有以 /app 开头的字符串”理解。

如果服务端没有显式设置 Path，客户端会根据设置 Cookie 的请求路径推导默认目录范围。为了让会话 Cookie 的行为稳定，我更倾向于对需要全站使用的会话明确写 Path=/，对只服务某个子应用的 Cookie 写出更窄的路径，并在接口文档中记录它。

cookie := &http.Cookie{
    Name:     "session_id",
    Value:    "demo-session",
    Path:     "/app", // 只让 /app 目录及其子路径匹配
    HttpOnly: true,   // 禁止浏览器脚本直接读取会话 Cookie
    Secure:   true,   // 仅通过 HTTPS 发送；本地 HTTP 调试需按环境调整
}
http.SetCookie(w, cookie) // 把 Cookie 写入当前响应的 Set-Cookie 头

这里的 Secure 会额外限制传输协议，不能把它和 Path 混为一谈；HttpOnly 也不改变请求路径匹配，只影响非 HTTP API 对 Cookie 的访问。

Domain 决定主机范围，而不是端口范围

省略 Domain 时，Cookie 通常只回到设置它的那个主机，这类 Cookie 可以理解为 host-only。显式写 Domain=example.com 后，范围可以覆盖 example.com 及其子域，例如 api.example.com；但客户端仍会拒绝与来源主机不相容的 Domain。

Domain 只描述主机匹配，不负责端口隔离。也就是说，同一主机不同端口的服务不能靠 Domain 做出独立域名边界；如果开发环境把前端、API 和测试服务放在不同端口，排查时还要结合 URL、Jar 状态和服务端实际响应头一起看。

用 cookiejar 按 URL 查询实际候选范围

下面的代码不启动服务器，而是直接把两个 Cookie 放入内存 Jar，再用不同 URL 调用 Cookies。它适合定位范围规则：先观察候选 Cookie，再回到真实响应检查服务端发送的属性。代码中的 example.com 仅是示例域名，不代表需要访问它。

package main

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

func names(jar *cookiejar.Jar, rawURL string) {
    u, err := url.Parse(rawURL)
    if err != nil {
        panic(err) // 示例直接终止；生产代码应把错误返回给调用方
    }
    for _, c := range jar.Cookies(u) {
        fmt.Printf("%s=%s; Path=%s; Domain=%s\n", c.Name, c.Value, c.Path, c.Domain)
    }
}

func main() {
    jar, err := cookiejar.New(nil)
    if err != nil {
        panic(err) // 创建内存 Jar 失败时不要继续发请求
    }

    base, _ := url.Parse("https://example.com/app/login")
    jar.SetCookies(base, []*http.Cookie{
        {Name: "app", Value: "A", Path: "/app"}, // /app 目录范围
        {Name: "shared", Value: "B", Domain: "example.com", Path: "/"}, // 主域及子域
    })

    names(jar, "https://example.com/app/report")       // 两个 Cookie 都可能匹配
    names(jar, "https://example.com/apple")            // app 不应仅因前缀相同而匹配
    names(jar, "https://api.example.com/app/report")   // shared 可按 Domain 匹配，app 仍是 host-only
}

这个例子里，app 没有 Domain，因此不会因为路径相同就自动扩展到 api.example.com；shared 显式指定了主域，才具备子域范围。真实业务中还要考虑 Secure、过期时间、公共后缀和多个同名 Cookie。

同名 Cookie、删除和安全边界怎么处理

同名不等于同一个 Cookie。不同 Path 或 Domain 可以让多个同名条目同时存在，服务端收到的 Cookie 头也可能包含多个同名键。因此删除会话 Cookie 时，过期 Cookie 的 Path 和 Domain 要与原条目匹配，否则看起来“删了”但旧条目仍可能被带上。

我通常会把范围设计成最小必要集合：单站会话明确 Path=/，跨子域共享前先确认信任边界；敏感会话同时评估 Secure、HttpOnly 和合适的 SameSite。不要把 Path 当成安全隔离手段，它主要是发送范围控制。

常见问题

Path=/app 会匹配 /apple 吗？

不应按普通字符串前缀理解。路径匹配还要看目录分隔边界，/app/report 属于子路径，而 /apple 不是。

省略 Domain 能让所有子域都收到 Cookie 吗？

不能这样设计。省略 Domain 通常得到 host-only Cookie，只回到设置它的主机；需要子域共享时应显式设计并评估信任范围。

Cookie 不发送，是 Path 还是 Domain 的问题？

先比较请求主机与 Cookie 的 Domain，再比较请求路径与 Path；随后检查 Jar 是否配置、协议是否满足 Secure，以及 Cookie 是否已过期。

不同端口能用 Domain 隔离 Cookie 吗？

不能。Domain 针对主机，不是端口。不同端口的服务仍可能共享同一主机范围，需要从部署域名或应用层命名与权限上解决。