Go 读取多个同名 Cookie 时怎么处理顺序和来源

同一个请求里出现两个或多个同名 Cookie 时，Go 的关键区别是：r.Cookie("sid") 只返回一个匹配项；Go 1.23 及以上应优先用 r.CookiesNamed("sid") 读取全部值。返回切片保留解析到的头部顺序，但这个顺序不是“最新登录”或“最可信来源”的证明。服务端拿到的 Cookie 请求头只有 name/value，不能反推出每个值原来的 Path、Domain、SameSite 或 Expires。

如果业务必须处理多个同名值，就先读取完整列表，再按明确的格式、签名、租户或会话规则筛选；不要把 Cookie 方法返回的第一个值直接当成来源判断。

先确认同名 Cookie 到底从哪里出现

排查时先不要猜浏览器为什么“选错了”。在服务端，最直接的证据是请求头本身。例如下面的请求包含两个 sid：

Cookie: sid=short-lived; theme=dark; sid=legacy

Go 的 Cookie 解析器会把它们视为两个独立的键值对。这里的 short-lived 排在前面，只能说明它在这条请求头中先出现。RFC 6265 描述了用户代理生成 Cookie 头时的常见排序建议：路径更长的在前，路径长度相同则创建时间更早的在前；规范同时提醒服务器不要错误依赖这个顺序。

还要区分两个方向。响应里的 Set-Cookie 可以带 Path=/admin、Domain=example.com、SameSite=Lax 和过期属性；请求里的 Cookie 只携带 name/value。于是服务端无法仅凭 sid=... 判断它来自哪个 Path，也无法确认它是否曾经设置过 SameSite。

用 CookiesNamed 保留所有同名值

Go 1.23 新增的 Request.CookiesNamed 正好对应这个问题。它只筛选指定 name，但不丢掉重复项。下面的处理把每个候选先做空值和格式检查，再交给业务层决定是否接受：

func readSessionIDs(r *http.Request) []string {
	// 读取同名 Cookie 的全部候选，不把第一个值当成最终来源。
	cookies := r.CookiesNamed("sid")
	ids := make([]string, 0, len(cookies))
	for _, cookie := range cookies {
		// 空值先跳过，格式校验应放在业务规则之前。
		if cookie == nil || cookie.Value == "" {
			continue
		}
		ids = append(ids, cookie.Value)
	}
	return ids
}

这个函数的结果仍然是“按头部顺序排列的候选值”，不是已经完成身份认证的会话。真实项目通常还要逐个校验签名、租户标识、版本和撤销状态，并规定多个候选同时有效时是拒绝请求、选择签名最新者，还是只保留一个规范 Cookie。

旧版本用 ParseCookie 或 Cookies 过滤

如果项目还没有 CookiesNamed，有两条兼容路线。Go 1.23 同时提供了 http.ParseCookie，它直接解析一行 Cookie 头并保留重复 name；更老的版本则可以遍历 r.Cookies()。

func allNamedCookies(r *http.Request, name string) ([]*http.Cookie, error) {
	// 取出客户端发送的单行 Cookie 头，避免只调用 r.Cookie。
	line := r.Header.Get("Cookie")
	if line == "" {
		return nil, http.ErrNoCookie
	}

	// ParseCookie 返回的切片顺序与头部片段顺序一致。
	parsed, err := http.ParseCookie(line)
	if err != nil {
		return nil, fmt.Errorf("parse cookie: %w", err)
	}
	matched := make([]*http.Cookie, 0, len(parsed))
	for _, cookie := range parsed {
		// 只收集精确 name，不能用包含关系代替键匹配。
		if cookie.Name == name {
			matched = append(matched, cookie)
		}
	}
	return matched, nil
}

若要兼容更早的 Go 版本，可把 http.ParseCookie 替换成 r.Cookies() 后按 cookie.Name == name 过滤。不要直接用 strings.Split 自己切分，因为引号、非法 name、值中出现特殊字符等情况都应交给 net/http 的解析逻辑。

把顺序交给明确的业务选择策略

读到多个值后，最容易犯的错是写出“取第一个就是当前 Cookie”。第一个只代表当前请求头中的位置；代理、客户端实现、路径重叠和历史残留都可能让它与开发者心中的“来源”不同。

可以把选择策略写成一个小函数：先拒绝格式错误的值，再验证签名，最后只接受一个有效候选；如果两个值都有效，宁可返回冲突，也不要静默选择。

func chooseSession(values []*http.Cookie) (string, error) {
	var selected string
	for _, cookie := range values {
		// 示例只保留具有固定前缀的候选，实际项目应校验签名和撤销状态。
		if cookie == nil || !strings.HasPrefix(cookie.Value, "v1.") {
			continue
		}
		if selected != "" && selected != cookie.Value {
			return "", errors.New("conflicting session cookies")
		}
		selected = cookie.Value
	}
	if selected == "" {
		return "", http.ErrNoCookie
	}
	return selected, nil
}

SameSite、Secure、HttpOnly、Max-Age 和 Expires 要在写出响应时设置，并通过正确的删除条件清理旧 Cookie。尤其是删除同名 Cookie 时，删除响应应匹配原 Cookie 使用过的 Path 和 Domain；但这些属性不会成为下一次请求中某个 sid 值的来源标签。

用测试请求验证最终选择

测试重点不是验证某个浏览器永远如何排序，而是锁定服务端面对输入时的行为：重复值全部保留、格式错误被拒绝、冲突不会静默通过、没有 Cookie 时返回明确错误。

func TestDuplicateCookiePolicy(t *testing.T) {
	// 构造重复 name 的原始请求，覆盖顺序和冲突分支。
	req := httptest.NewRequest(http.MethodGet, "/profile", nil)
	req.Header.Set("Cookie", "sid=v1.old; theme=dark; sid=v1.new")

	values := req.CookiesNamed("sid")
	if len(values) != 2 || values[0].Value != "v1.old" || values[1].Value != "v1.new" {
		t.Fatalf("unexpected cookies: %#v", values)
	}
	if _, err := chooseSession(values); err == nil {
		// 两个不同的有效格式应被视为冲突，而不是自动选一个。
		t.Fatal("expected conflicting session cookies")
	}
}

最终检查清单是：需要一个值时明确调用 Cookie 还是全量读取；需要全量时保留切片顺序；选择逻辑不依赖未传回的 Path、Domain 或 SameSite；删除旧 Cookie 时匹配设置时的作用域；重复候选同时有效时有可观测的冲突结果。

相关问题

为什么 r.Cookie("sid") 不报错却拿不到第二个值？

它的 API 约定就是返回一个匹配项。需要全部同名值时改用 CookiesNamed，或遍历 Cookies。

能不能从请求 Cookie 判断它来自哪个 Path？

不能。请求头只带 name/value；Path、Domain 等是用户代理保存和发送时使用的属性，不会附在单个值后面。

多个同名 Cookie 应该选最新的吗？

不要用“最新”这个无法证明的判断。按签名、租户、版本和撤销状态建立明确策略；发生冲突时拒绝或进入人工可观测的异常分支。

参考资料：Go net/http 文档、Go 1.23 发布说明、RFC 6265 Cookie 规范。