Go net/http.Request.CookiesNamed 怎么筛选同名 Cookie：返回切片与请求头顺序

排查登录态时，日志里偶尔会出现两个同名 sid Cookie。只调用 Request.Cookie("sid") 很容易把问题藏起来：它只返回一个匹配项，而 Request.CookiesNamed("sid") 会把同名 Cookie 全部取出。Go 1.23 起，这个方法适合做重复值检查、顺序核对和异常请求审计。

开发 Go 接口时，如果遇到前端提交多个同名 Cookie 的场景，直接用 http.Request 的 CookiesNamed 方法就能把所有同名 Cookie 整合成切片返回，而且返回结果会保留 HTTP 请求头里 Cookie 字段的解析顺序，不用自己手动解析原始 Cookie 字符串。

Go 标准库 net/http 里的 (*Request).CookiesNamed 方法，会把所有匹配指定名称的 Cookie 对象以切片形式返回，返回顺序对应客户端发来的 Cookie 排列顺序，不会自动去重丢弃同名项。

为什么单值读取会漏掉异常请求

Cookie 规范允许请求头中出现多个 Cookie 字段名相同的条目。业务代码如果只关心“有没有 sid”，r.Cookie("sid") 看起来够用；但在登录态切换、代理拼接请求头或旧 Cookie 没清干净的场景里，重复值本身就是需要记录的信号。

Go 官方文档对两个方法的语义区分得很明确：Cookie 返回一个匹配项，CookiesNamed 返回全部匹配项。安全敏感的请求不要先取一个值再忽略其余内容。

用同一份请求复现 CookiesNamed 的顺序

下面的示例不依赖真实网络连接，只构造一个 GET /account 请求，并写入两个 sid 与一个 theme。运行命令：

go run article-drafts/1788064797-45-go-cookiesnamed/example.go

关键输出应包含 count=2，并按 first、second 的顺序返回。这个顺序来自请求头解析结果，不代表哪一个 Cookie 更可信。

Cookie 与 CookiesNamed 的取值边界

如果业务明确要求只能存在一个登录 Cookie，可以先调用 CookiesNamed，只有长度为 1 时才进入后续鉴权。不要用 Cookie 的成功返回替代这项检查，因为重复 Cookie 仍会被它隐藏。

sidCookies := r.CookiesNamed("sid")
if len(sidCookies) != 1 {
    return fmt.Errorf("sid cookie count=%d", len(sidCookies))
}
sid := sidCookies[0].Value
// 只有通过重复值检查后，才把 sid 交给会话校验逻辑。
_ = sid

原示例同时调用 Cookie("sid") 和 Cookie("missing")。前者只显示一个值，后者返回 http.ErrNoCookie；第二个结果适合区分“没有 Cookie”和“Cookie 存在但值为空”。

把重复 Cookie 变成可执行的检查

登录、改密和管理员接口可以把重复 sid 视为异常输入：记录请求 ID、Cookie 数量和来源链路，随后拒绝或进入重新登录流程。普通偏好设置则可以允许多个值，但仍应明确选择规则，避免不同中间件各取一个。

这里别急着把返回切片排序或去重。排序会丢失请求头顺序，去重会掩盖重复出现的事实；先在边界层保留原始观察结果，再把业务允许的选择规则写出来。

常见问题

CookiesNamed 找不到名称时会返回 nil 吗？

文档语义是返回空切片。调用方应先检查 len，不依赖 nil 与非 nil 的细微差异。

CookiesNamed 会把同名 Cookie 自动合并吗？

不会。它返回多个 Cookie，示例中的 first 和 second 仍是两个独立元素。

什么时候还能直接使用 Cookie？

当业务明确只需要一个值，并且已通过重复值检查时可以使用；涉及会话、权限和签名时，优先先检查 CookiesNamed。

结论：先看数量，再决定取哪个值

CookiesNamed 解决的是“同名 Cookie 是否全部可见”的问题，Cookie 解决的是“取一个匹配值”的问题。把数量、顺序和缺失错误写进边界检查，才能让登录态异常在鉴权前暴露出来。