Go http.CookieJar重定向时保留正确 Cookie的配置方法

Go 里想让 HTTP 请求在重定向后继续使用登录态，关键不是手动把同一个 Cookie 请求头复制到下一跳，而是创建一个 cookiejar.Jar 并挂到同一个 http.Client。Client 会把 Jar 用于每次重定向：响应里的 Set-Cookie 先更新 Jar，下一次请求再按目标 URL 的域名、路径和安全属性挑选 Cookie。

CookieJar、Client 和重定向请求的关系

cookiejar 实现了 http.CookieJar 接口，核心状态放在内存 Jar 中。http.Client 发出请求前会从 Jar 取出适用于当前 URL 的 Cookie，收到响应后再把 Set-Cookie 写回 Jar；重定向发生时，Client 会重新咨询这个 Jar，而不是无条件沿用初始请求的 Cookie 头。

最小配置可以这样写。代码里的 PublicSuffixList 不是为了让 Cookie 更容易跨域，而是限制服务器能把 Cookie 设置到哪个公共后缀之下。

package main

import (
	"fmt"
	"net/http"
	"net/http/cookiejar"
	"time"

	"golang.org/x/net/publicsuffix"
)

func newClient() (*http.Client, error) {
	// 公共后缀列表限制跨站域 Set-Cookie，生产环境不要用 nil 放宽边界。
	jar, err := cookiejar.New(&cookiejar.Options{
		PublicSuffixList: publicsuffix.List,
	})
	if err != nil {
		return nil, fmt.Errorf("create cookie jar: %w", err)
	}

	return &http.Client{
		Jar: jar,
		// 限制异常重定向链，避免错误配置让请求持续跳转。
		CheckRedirect: func(req *http.Request, via []*http.Request) error {
			if len(via) >= 8 {
				return http.ErrUseLastResponse
			}
			return nil
		},
		Timeout: 10 * time.Second,
	}, nil
}

这里的 CheckRedirect 只负责重定向政策，不负责把 Cookie 从旧 URL 强行复制到新 URL。若返回 http.ErrUseLastResponse，Client 会停在当前响应；若允许继续，Jar 仍会按照下一跳 URL 的规则筛选 Cookie。

公共后缀和初始 Cookie 要分开处理

cookiejar.New(nil) 适合测试，但官方文档明确提示，空的公共后缀实现不安全：一个站点可能为另一个同公共后缀的站点设置 Cookie。生产代码通常引入 golang.org/x/net/publicsuffix，把 publicsuffix.List 传给 Jar。

初始凭据也有两种情况。临时测试值可以用 req.AddCookie 写入单个请求；需要跨多次请求和重定向维护的状态，则应让服务器通过 Set-Cookie 更新 Jar。直接设置 req.Header.Set("Cookie", ...) 不会把这个字符串变成 Jar 中的持久条目，后续跳转可能仍按 Jar 的真实状态发送。

如果服务端在第一跳把 session 更新为新值，带非空 Jar 的 Client 会优先依据 Jar 里的更新值组装下一跳 Cookie。这个行为也解释了为什么手工复制初始 Cookie 头容易造成旧会话覆盖新会话。

按 URL 边界排查 Cookie 没有被带上

Cookie 没出现在重定向请求里时，按下面的顺序检查，比修改请求头更可靠：

可以在重定向回调里只记录 URL 和 Cookie 名称，不要记录真实 Cookie 值：

CheckRedirect: func(req *http.Request, via []*http.Request) error {
	// 只输出排查所需的元数据，避免把会话值写入日志。
	fmt.Printf("redirect=%d host=%s path=%s cookies=%d\n",
		len(via), req.URL.Host, req.URL.Path, len(req.Cookies()))
	return nil
},

可复用的配置清单与边界

一个稳定的实现通常只保留三条原则：同一登录流程复用同一个 http.Client；Jar 使用可信公共后缀列表；重定向回调只控制跳转上限和可信目标，不篡改 Cookie 作用域。对跨域登录、不同站点之间的跳转，不能把“保留 Cookie”理解为“所有 Cookie 都应该保留”。

最后用 jar.Cookies(targetURL) 查看某个目标 URL 当前可见的 Cookie 名称，结合响应的 Set-Cookie 属性逐项比对。这样既能保留正确会话，也能避免为了追求“跳转后有 Cookie”而扩大敏感凭据的发送范围。

相关问题

为什么 CookieJar 配置了却没有 Cookie？

先确认请求使用的就是挂载 Jar 的那个 Client，再检查目标 URL 是否满足 Domain、Path 和 Secure 条件；如果服务端没有发出有效的 Set-Cookie，Jar 也不会凭空生成会话。

CheckRedirect 里要不要手动添加 Cookie？

通常不要。非空 Jar 会被 Client 自动咨询。手动复制 Cookie 头容易绕过作用域判断，还可能覆盖重定向过程中服务端刚更新的值。

PublicSuffixList 传 nil 可以吗？

可以用于测试或受控实验，但生产环境不建议这样做。使用 publicsuffix.List 能避免把公共后缀下的站点错误地视为同一 Cookie 域。