Go http.CookieJar在测试环境处理 Secure 属性的排查方案

我在 Go 的接口测试里遇到过一种很容易误判的现象：登录响应明明设置了 Secure Cookie，第二次请求却没有会话。先给结论：Secure 不是“只在浏览器里生效”的装饰字段，cookiejar.Jar 会把它当成投递条件；测试请求若使用 http://，就不应期待这个 Cookie 出现在 Jar.Cookies(u) 的结果里。测试非安全 Cookie 可以继续用 HTTP，测试安全 Cookie 则应让测试入口真正使用 HTTPS。

测试环境处理 Go http.CookieJar 的 Secure 属性，核心是让 Cookie 的来源 URL、请求 URL 和测试协议保持一致：要验证 Secure Cookie，就使用 HTTPS 测试入口；要验证普通 HTTP 会话，就不要把 Cookie 标成 Secure。

Secure Cookie 先看 scheme，不要先改 Jar

http.Cookie 的 Secure 字段表达的是安全传输限制。cookiejar.Jar 实现 http.CookieJar，调用 Cookies(u) 时会按请求 URL 的规则筛选 Cookie。于是，同一个主机、同一路径下，https://api.example.test/ 与 http://api.example.test/ 的结果可能不同。

package main

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

func main() {
    jar, err := cookiejar.New(nil)
    if err != nil {
        panic(err)
    }
    secureURL, _ := url.Parse("https://api.example.test/login")
    httpURL, _ := url.Parse("http://api.example.test/api")

    // 用 HTTPS 作为 Cookie 的来源，表示服务端在安全入口设置它。
    jar.SetCookies(secureURL, []*http.Cookie{{Name: "sid", Value: "demo", Secure: true, Path: "/"}})
    fmt.Println("HTTPS:", len(jar.Cookies(secureURL)))
    // 这里故意使用 HTTP，Secure Cookie 不应被当作普通 Cookie 投递。
    fmt.Println("HTTP:", len(jar.Cookies(httpURL)))
}

这里要分清“保存”和“投递”两个动作。SetCookies 把响应中的 Cookie 交给 Jar 管理，Cookies(u) 再依据目标 URL 返回可发送的集合。看到 HTTP 结果为空时，优先检查 u.Scheme，不要马上把 Secure 改成 false 来迎合测试。

测试入口必须和 Cookie 来源保持同协议

最常见的错配是：测试服务器用 httptest.NewServer，接口逻辑却按照生产 HTTPS 返回 Secure Cookie。此时测试客户端即使挂载了 Jar，第二个 HTTP 请求也不会自然带上该 Cookie。若目标是验证登录态在 HTTPS 下能否延续，应改用 TLS 测试服务器，并复用它提供的 Transport。

func newTLSClient(ts *httptest.Server, jar http.CookieJar) *http.Client {
    // TLS 测试服务器的 Transport 已包含测试证书信任配置，直接复用可避免自建 TLS 配置偏差。
    return &http.Client{Transport: ts.Client().Transport, Jar: jar}
}

// 使用示意：ts := httptest.NewTLSServer(handler)
// defer ts.Close() // 测试结束及时释放监听资源。
// client := newTLSClient(ts, jar)
// resp, err := client.Get(ts.URL + "/profile")

如果当前测试只想验证业务处理，不关心安全传输，那么可以保留 NewServer，但服务端应设置普通 Cookie，或在断言中明确这是 HTTP 场景。不要一边使用 HTTP，一边声称已经验证了生产的 Secure 会话行为。

四项清单能定位大多数 Cookies(u) 为空

排查时建议先直接查看 jar.Cookies(targetURL)，再看请求是否由 http.Client 自动携带。req.AddCookie 是手工注入，它可以测试服务端如何解析 Header，却不能证明 CookieJar 的 Secure 策略正确。另一个边界是 cookiejar.Jar 只对 HTTP/HTTPS URL 工作，使用自定义 scheme 得不到有意义的匹配结果。

Go http.CookieJar Secure 属性的相关问题

把 Secure 改成 false 能解决测试失败吗？

只能让它符合 HTTP 投递条件，却会改变被验证的安全语义。只有在测试目标本来就是普通 HTTP 会话时才这样设置。

httptest.NewServer 能测试 Secure Cookie 吗？

它提供 HTTP 地址，适合验证非 Secure Cookie。要验证 Secure Cookie 的投递，应使用 httptest.NewTLSServer 及其客户端 Transport。

为什么 Jar 里可能有 Cookie，但请求仍没有它？

Jar 保存的集合和针对某个 URL 筛选出的集合不是一回事。Secure、Host、Domain、Path 和有效期任一条件不满足，都可能让目标 URL 的结果为空。

把测试协议写进测试命名和断言，通常比在失败后临时放宽 Cookie 属性更稳：HTTP 测试验证业务流程，TLS 测试验证 Secure 会话，两个目标分开，失败原因也更清楚。