Go CookieJar 在本地 HTTP 测试中为什么不发送 Secure Cookie

在 Go 的本地 HTTP 测试里，CookieJar 取不到一个带 Secure 属性的 Cookie，通常不是 Jar 丢了数据，而是请求 URL 仍然是 http://。Secure 的含义就是只允许 Cookie 随 HTTPS 请求发送；本机地址、localhost 或测试环境并不会自动把普通 HTTP 变成安全连接。

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

先把“Cookie 存在”与“请求会发送”分开

排查时最容易混淆的是两个动作：服务器响应中的 Set-Cookie 可能已经被 Jar 接收，但这不代表它对下一条请求一定可用。Jar 在 Cookies(u) 中还要把 URL 的 scheme、主机、Path、过期时间和 Secure 标记放在一起判断。

对本篇问题而言，关键只有一条：目标 URL 是 http 时，带 Secure 的 Cookie 不属于应该发送的候选；目标 URL 是 https 时，才具备满足该属性的 scheme 条件。把服务地址改成 localhost，不会绕过这个判断。

用同一个 Jar 对比 HTTP 和 HTTPS 的筛选边界

下面的代码只展示判断关系，不依赖浏览器。先向 Jar 放入一个带 Secure 的 Cookie，再分别询问两个 scheme 的 URL。读取结果时关注的是“候选列表是否为空”，而不是把 Jar 当成无条件的键值存储。

package main

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

func main() {
    // 使用标准库 Jar 保存测试会话 Cookie；这里不涉及浏览器策略。
    jar, err := cookiejar.New(nil)
    if err != nil {
        panic(err)
    }

    // Secure 表示只允许满足安全 scheme 的请求使用它。
    secureCookie := &http.Cookie{Name: "sid", Value: "test", Secure: true, Path: "/"}
    base, err := url.Parse("https://127.0.0.1/")
    if err != nil {
        panic(err)
    }
    jar.SetCookies(base, []*http.Cookie{secureCookie})

    // 同一个 Jar 查询两种 scheme，才能看清筛选条件的差异。
    httpURL, _ := url.Parse("http://127.0.0.1/")
    httpsURL, _ := url.Parse("https://127.0.0.1/")
    fmt.Println("HTTP cookies:", jar.Cookies(httpURL))
    fmt.Println("HTTPS cookies:", jar.Cookies(httpsURL))
}

这段示意中，HTTP 查询不应把 sid 放进待发送列表，HTTPS 查询才满足 Secure 的 scheme 条件。实际项目还会受到 Domain、Path 和过期时间影响，所以不能只拿一个空列表就断言“Jar 没保存”。

本地测试应该改协议，还是改 Cookie 属性

如果测试目标是登录、会话续期或需要复现生产 HTTPS 行为，优先让测试链路使用 HTTPS，再把同一个 Jar 交给 http.Client。这样测试验证的是生产约束，而不是通过删除 Secure 来掩盖协议差异。

如果测试目标只是验证一个普通 HTTP Handler 的业务分支，那么测试 Cookie 可以不设置 Secure。这不是降低生产安全性，而是让测试数据与被测协议保持一致；生产配置仍应按真实 HTTPS 部署要求设置。

client := &http.Client{
    // Client 必须引用保存会话的同一个 Jar，否则响应 Cookie 不会被复用。
    Jar: jar,
}

// 真实 HTTPS 测试使用 tls 测试地址；普通 HTTP 单测则使用非 Secure Cookie。
target := "https://127.0.0.1/next"
req, err := http.NewRequest(http.MethodGet, target, nil)
if err != nil {
    panic(err)
}
resp, err := client.Do(req)
if err != nil {
    panic(err)
}
defer resp.Body.Close() // 关闭响应体，避免测试连接资源泄漏。

几个看起来像同一个问题的边界

第一，Jar 为空不一定是 Secure 导致。如果 URL scheme 不是 HTTP 或 HTTPS，官方文档明确说明 Cookies 会返回空切片；拼写错误、使用自定义 scheme 时应先检查 URL 解析结果。

第二，localhost 不是安全协议。本机域名只影响主机匹配，不能替代 TLS。测试中若要保留 Secure 语义，应使用 HTTPS 测试地址，而不是只把服务监听地址改成 localhost。

第三，不要把浏览器规则套到 Jar 上。本文只讨论 Go net/http/cookiejar 的 URL 匹配；浏览器对 SameSite、第三方 Cookie 等还有自己的策略，不能用来解释一个 Go 客户端 Jar 的筛选结果。

常见问题

把 Secure 改成 false 就一定能发送吗？

不一定。还要同时满足 URL 的域名、Path、有效期等条件，并且客户端确实绑定了这个 Jar。

为什么 HTTPS 查询仍然拿不到 Cookie？

优先检查 Cookie 的 Domain、Path、过期时间和保存时使用的 URL，再确认发请求的 http.Client 使用的是同一个 Jar。

本地测试是否应该永远去掉 Secure？

不应该。需要覆盖生产会话链路时保留 Secure 并使用 HTTPS；只测试普通 HTTP 业务分支时，才使用与协议一致的非 Secure 测试 Cookie。

小结：CookieJar 不是“存进去就必发”的容器。Secure Cookie 在本地 HTTP 测试中不发送，是 URL scheme 与 Cookie 属性不匹配的正常结果；先确定测试想覆盖的协议，再选择 HTTPS 测试链路或非 Secure 测试数据。