Go http.Cookie 不生效怎么办

我排查 Go 登录态时最容易先看错地方：服务端明明调用了 http.SetCookie，却在同一个请求里用 r.Cookie 期待立刻读到它。Cookie 的方向其实相反：服务端先在响应中发出 Set-Cookie，浏览器或带 Jar 的 Go 客户端保存后，下一次请求才会带上 Cookie。所以“Go http.Cookie 不生效”通常不是结构体失效，而是链路中的某一段没有完成。

先分清 Set-Cookie 和 Cookie 的方向

http.Cookie 只是 HTTP Cookie 的数据表示。响应阶段要写入 Set-Cookie，请求阶段才从 Cookie 头解析。服务端登录接口可以这样写：

func login(w http.ResponseWriter, r *http.Request) {
	// 先写 Set-Cookie，让客户端保存登录态。
	http.SetCookie(w, &http.Cookie{
		Name:     "session_id",
		Value:    "demo-123",
		Path:     "/", // 让同一站点的其他路径也能携带
		HttpOnly: true,
		SameSite: http.SameSiteLaxMode,
	})
	// 不要在 Write 或 WriteHeader 之后才补 Cookie。
	w.WriteHeader(http.StatusNoContent)
}

func profile(w http.ResponseWriter, r *http.Request) {
	c, err := r.Cookie("session_id")
	if err != nil {
		// 没有 Cookie 时要区分 ErrNoCookie 与其他解析错误。
		http.Error(w, "missing session", http.StatusUnauthorized)
		return
	}
	fmt.Fprintln(w, c.Value)
}

这里的关键不是把 Cookie 写进响应头，而是让客户端收到 Set-Cookie 后，在后续请求的 Cookie 头中回传。若你在登录处理函数里立刻读取 r.Cookie，读到的仍是进入当前请求时携带的旧状态。

把 Cookie 交给浏览器或 CookieJar 管理

浏览器通常会替你保存和发送 Cookie，但它仍会检查域、路径、Secure、SameSite 等属性。Go 客户端则不能想当然地“自动记住”：为跨请求保留状态时，应把同一个 Jar 交给 http.Client。

jar, err := cookiejar.New(nil)
if err != nil {
	// 创建 Jar 失败时直接结束，避免后续请求看起来像 Cookie 丢失。
	log.Fatal(err)
}
client := &http.Client{Jar: jar}

resp, err := client.Get(serverURL + "/login")
if err != nil {
	log.Fatal(err)
}
// 读取完响应体再关闭，保持客户端资源边界清晰。
io.Copy(io.Discard, resp.Body)
resp.Body.Close()

resp, err = client.Get(serverURL + "/profile")
if err != nil {
	log.Fatal(err)
}
defer resp.Body.Close()

// 需要观察客户端是否保存时，可查询同一个 URL 的 Jar 状态。
u, _ := url.Parse(serverURL + "/profile")
for _, c := range jar.Cookies(u) {
	fmt.Println(c.Name, c.Value)
}

如果只需要给某一个请求附加 Cookie，不必创建 Jar：

req, err := http.NewRequest(http.MethodGet, serverURL+"/profile", nil)
if err != nil {
	log.Fatal(err)
}
// AddCookie 会把这个 Cookie 合并到请求的 Cookie 头中。
req.AddCookie(&http.Cookie{Name: "session_id", Value: "demo-123"})
resp, err := http.DefaultClient.Do(req)
if err != nil {
	log.Fatal(err)
}
defer resp.Body.Close()

写入时机和字段合法性要逐项排查

我通常先把配置缩到下面这组最小值，再逐项恢复业务属性。Path 先设为 /；不确定时不要先写 Domain，让它成为当前主机的 host-only Cookie；本地 HTTP 调试不要误加 Secure。如果确实是跨站场景，再单独验证 SameSite=None 与 HTTPS 条件。

字段本身也可能让结果看起来“没生效”。Go 文档说明，Cookie 名称必须合法；名称非法时 String 会得到空字符串，SetCookie 可能静默丢弃。值里的控制字符、分号和反斜杠也不能直接当普通文本塞进去。可以在发送前显式调用 Valid：

c := &http.Cookie{Name: "session_id", Value: "demo-123", Path: "/"}
if err := c.Valid(); err != nil {
	// 先暴露字段错误，避免只看到客户端没有保存的结果。
	log.Printf("invalid cookie: %v", err)
	return
}
http.SetCookie(w, c)

用最小复现定位发送条件

排查时不要一次把所有属性都改掉。先确认响应头确实有 Set-Cookie: session_id=demo-123; Path=/，再确认客户端第二次请求的 URL 仍是同一主机和路径。Go 客户端可以分别查看 jar.Cookies(u) 和服务端收到的 r.Cookies()：前者为空，问题在保存或匹配条件；前者有值但服务端为空，问题在请求构造、URL 或中间层。

我会把一次失败请求固定记录成 4 个观测值：响应头是否有 Set-Cookie、Jar.Cookies(url) 是否有值、第二次请求是否出现 Cookie、服务端 r.Cookie 是否成功。四个值都能复现时，排查结果就不再是“好像生效了”，而是能明确指出哪一段为 0。我的基线通常是最小配置；恢复一个属性后只改变一个变量，再对比这 4 个值。

最终对比可以这样读：响应头为 1、Jar 为 0，先看客户端是否保存或 URL 是否匹配；响应头和 Jar 都为 1、请求头为 0，优先看 Path、Domain、Secure、SameSite；请求头为 1、服务端读取为 0，则检查中间层是否改写了 Header 或 Cookie 名称。这个结果表比单纯增加重试次数更有用。

常见问题

为什么调用 SetCookie 后当前请求还是取不到 Cookie？

因为 SetCookie 写的是当前响应，Cookie 要到客户端收到响应后才可能出现在下一次请求。

http.Client 为什么第二次请求没有自动带 Cookie？

没有复用带 Jar 的客户端，或客户端的 Jar 为空。为会话请求创建一个 Jar 并复用同一个 Client。

Cookie 的 Domain 可以随便写吗？

不能。先省略 Domain 验证 host-only 流程；确需共享子域时，再确认 Domain 与当前主机、公共后缀和部署拓扑匹配。

Cookie 值为什么在响应里变了或被删掉？

Cookie 序列化会按合法字符规则处理值；先调用 Valid 检查 Name、Value、Path、Domain 和其他属性，避免用非法字符承载未编码数据。