Go Request.Cookies 处理同名 Cookie 的读取顺序

排查登录态时，我遇到过一个很容易误判的现象：请求里同时出现两个同名 sid，业务却只拿到其中一个。结论先说清楚：Request.Cookies() 会按请求头中 Cookie 片段的出现顺序返回全部可解析 Cookie；Request.CookiesNamed("sid") 会保留这个顺序筛出所有同名值；Request.Cookie("sid") 只返回匹配结果里的第一个。这个“第一个”是输入顺序，不代表最新、最安全或一定应该被采用。

官方地址：https://pkg.go.dev/net/http

先把同名 Cookie 的输入顺序固定下来

为了复现，不需要真的启动服务，直接构造一个请求，把 Cookie 头写成 sid=old; sid=new; theme=dark。这里的 old、new 只是演示值，不能据此推断浏览器或 CookieJar 已经判断了新旧。

package main

import (
    "fmt"
    "net/http"
)

func main() {
    req, err := http.NewRequest(http.MethodGet, "https://example.test/profile", nil)
    if err != nil {
        panic(err) // 构造请求失败时立即停止，避免继续分析空请求
    }
    req.Header.Set("Cookie", "sid=old; sid=new; theme=dark") // 保留重复值和输入顺序

    for i, c := range req.Cookies() {
        fmt.Printf("%d: %s=%s\\n", i, c.Name, c.Value) // 观察解析后的切片顺序
    }
}

这个示例会得到 sid=old、sid=new、theme=dark。源码的解析过程是先遍历 Header["Cookie"] 的各行，再按每行里的分号片段追加，因此结果顺序来自输入，而不是按名字分组后重排。

CookiesNamed 和 Cookie 的差异在“取几个”

Go 1.23 及以上可以用 CookiesNamed 只取指定名称，同时保留全部匹配项。若只调用 Cookie("sid")，实现会遍历匹配结果并立即返回第一个，所以它的行为更像“按既定优先级取首项”，而不是“帮你找最新会话”。

named := req.CookiesNamed("sid")
fmt.Println("同名数量:", len(named)) // 重复值应先被看见，再决定业务策略

sid, err := req.Cookie("sid")
if err != nil {
    fmt.Println("sid 不存在:", err) // 没有匹配值时处理 http.ErrNoCookie
} else {
    fmt.Println("单值读取:", sid.Value) // 这里只会得到第一个匹配值
}

如果项目还要支持更早的 Go 版本，可以遍历 req.Cookies() 自己筛选名称，但要把“返回全部”与“取哪一个”拆成两个函数，避免在循环里悄悄覆盖变量。

不要把最后一个值当成最新会话

同名 Cookie 常见于不同 Path 或 Domain 的历史残留，也可能来自手工拼接的请求头。服务端只看到当前请求携带的字符串，不能仅凭 old、new 这样的值判断哪个更新。更稳妥的做法是把重复值当成异常输入：

生产代码不要记录完整 Cookie 值；只记录名称、数量和请求追踪号。若你控制写入端，优先清理旧 Path 的 Cookie，再保证同一名称只对应一个明确作用域。

相关问题

Request.Cookies 会自动去重吗？

不会。只要片段能被解析，同名项会作为多个 *http.Cookie 返回。

Cookie("sid") 取第一个还是最后一个？

它返回解析结果中的第一个匹配项。这个顺序来自请求输入，不能解释成“最新值”。

什么时候应该用 CookiesNamed？

需要检查重复、统计数量或自行制定冲突策略时使用；如果业务确实只允许一个值，也应先确认数量再取值。

把 Cookies() 当作原始解析结果，把 Cookie() 当作明确的首项选择器，重复值处理就不会被一个看似简单的读取调用掩盖。