Go http.ParseCookie 遇到同名 Cookie 时怎样保留多个值

http.ParseCookie 返回的是 []*http.Cookie，同一个 Name 可以对应多个元素。要保留多个值，遍历结果时用 map[string][]string 追加 Value；如果还关心各名称之间的整体顺序，则同时保留原列表。不要把它改成单值 map 后再寻找“丢失”的 Cookie。

例如 theme=light; zone=west; theme=dark 中，theme 的两个值都应该进入列表。解析负责保留输入项，业务最终用哪一项是另一个决定，不能让一次 map 赋值无声地替代业务规则。

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

先明确小工具要保留什么

本文的小工具只做一件事：接收一组 Cookie 头值，返回有序 Cookie 列表和按名称分组的多值索引。它不启动服务，不使用 CookieJar，也不替应用自动选择某个同名值。

首先确认输入是请求的 Cookie 头值，而不是包含 Cookie: 前缀的整条文本。响应中的 Set-Cookie 则是另一种输入格式，有单独的 ParseSetCookie 接口，不能直接混在这组数据里。

ParseCookie 从 Go 1.23 开始提供。使用前可确认项目工具链包含该函数；若项目编译提示函数未定义，先查工具链版本，而不是把标准库列表语义改成手写字符串覆盖。下面所有示例都采用当前官方接口，未在本地运行。

最小代码：列表保留顺序，分组保留多个值

Ordered 保存解析得到的元素，ByName 保存每个名称的值切片。ByName 便于查找，但它不能表达不同名称之间的完整交错顺序，所以两个视图各有用途。

package main

import (
    "fmt"
    "net/http"
)

type cookieView struct {
    Ordered []*http.Cookie
    ByName  map[string][]string
}

func parseLines(lines []string) (cookieView, error) {
    view := cookieView{ByName: make(map[string][]string)}
    for i, line := range lines {
        cookies, err := http.ParseCookie(line)
        if err != nil {
            // 头值按一开始编号；不返回可被误用的半份结果。
            return cookieView{}, fmt.Errorf("Cookie 头值 %d 解析失败: %w", i+1, err)
        }
        for _, c := range cookies {
            view.Ordered = append(view.Ordered, c)
            // 同名值用追加保存，不用单值赋值覆盖。
            view.ByName[c.Name] = append(view.ByName[c.Name], c.Value)
        }
    }
    return view, nil
}

func main() {
    // 全部是自造样本，不含真实会话标识。
    view, err := parseLines([]string{"theme=light; zone=west; theme=dark; empty="})
    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Printf("theme 的多个值: %q\n", view.ByName["theme"])
    for i, c := range view.Ordered {
        // 仅为展示样本顺序；实际请求不应照搬为完整值日志。
        fmt.Printf("项 %d: %s=%q\n", i+1, c.Name, c.Value)
    }
}

核心就在 append：先取得同名值切片，再追加当前 Value。原来若写成 values[c.Name] = c.Value，后一个 theme 就会覆盖前一个；这不是 ParseCookie 去重，而是应用选择了单值数据结构。

这里的错误策略是整组拒绝：任何头值解析失败，都返回错误与空结果，防止调用方忽略错误后继续使用半份数据。它是本文辅助函数的约定，不代表所有项目都必须采取相同策略。需要逐条诊断时，应另行定义成功项与错误项如何同时返回。

按样本推导结果，定位覆盖发生在哪一层

按样本语义，theme 分组里应依次保留 light、dark，Ordered 中应有 theme、zone、theme、empty 四项。empty 的值是空字符串，仍然是一项存在的 Cookie。这些是代码推导的预期，本文没有展示伪造的终端输出。

如果上层只看到 dark，应先检查是否把 ByName 又转回单值结构。如果分组里有两个值，但页面只显示一个，则看展示模板是否只取切片末项。每一层都保留切片，才能把解析结果完整送到业务接口。

也不要用遍历 map 的顺序解释请求顺序。名称分组是查找索引，整体顺序由 Ordered 表达；只需要输出特定名称时，读取对应切片即可，无需依赖 map 的遍历次序。

接入 Request 时逐条处理 Cookie 头

已有 Request 时，可以把 Header.Values("Cookie") 交给辅助函数，按返回切片中的顺序逐条解析。不要只用 Header.Get 取得单个头值后，就假定自己已经处理了请求中的全部 Cookie 信息。

// 接入层复用前面的 parseLines，不启动服务器。
func fromRequest(r *http.Request) (cookieView, error) {
    if r == nil {
        return cookieView{}, fmt.Errorf("请求为空")
    }
    // Values 保留本次请求中已解析到的多条 Cookie 头值。
    return parseLines(r.Header.Values("Cookie"))
}

这个局部函数与前面的类型、导入和 parseLines 放在同一包中使用。它不新增服务入口；接入现有 handler 时，调用它并处理返回错误即可。无 Cookie 头时，输入切片为空，得到空列表与空索引，不需要伪造一条空头值。

逐条解析还能定位是哪一个头值失败。不要先用逗号拼接 Cookie 头值再解析，因为 Cookie 的条目分隔形式不是通用逗号列表。这里保留的是 Request 中已经存在的头值序列，不宣称能还原网络传输前被代理重排或改写的内容。

空值、错误与引号不能混为一谈

empty= 表示名称存在且值为空；空白的整个输入值则可能是解析错误；完全没有该名称，又是另一种情况。业务读取分组时可使用 map 查找的 ok 或切片长度，区分不存在和存在空值，不要仅用字符串是否为空判断。

引号同样需要分层理解。ParseCookie 会按 Cookie 值规则处理引号，并在 Cookie 的 Quoted 字段中记录相关信息。本文的 ByName 只提取 Value，因此没有保留全部表示细节；需要这些信息时，使用 Ordered 中的完整 Cookie 对象。

遇到无效名称、无效值或缺少等号等输入，应检查 ParseCookie 返回的错误。不要为了“尽量拿到两个同名值”而把解析错误忽略掉，随后把空结果解释成没有重复项。请求头已经有长度和数量限制时，也应沿用应用现有边界，不把本例误当成无限输入收集器。

解析也不负责恢复来源范围。浏览器可能因为不同 Path 等原因发送同名 Cookie，但请求 Cookie 头主要携带名称和值，不能从两个同名元素中可靠反推出原来各自的 Domain、Path。值的先后是观察结果，不是来源证明。

交给业务前再决定同名值的使用规则

小工具完成后，上层收到的是全部观察值。业务可以明确拒绝不允许重复的名称，或者在自己的协议中约定如何处理多个值；关键是把这个选择写在使用层，避免解析层默认只留下最后一个。

如果一个名称按业务定义必须唯一，发现两个相同值也仍然是两个输入项，不能先去重再声称没有重复。同理，“第一个值”或“最后一个值”只是规则选项，标准库返回列表不等于替应用认可了某一种选择。

• 输入使用 Cookie 头值，不带头名前缀，不混入 Set-Cookie。
• 原始解析结果用列表保存，多值索引用 append 构建。
• 需要全部头值时逐条处理，错误保留头值序号。
• 区分空值、缺失名称、空头值和解析失败。
• 业务选择在解析之后明确执行，不通过单值 map 隐式覆盖。

同名且同值，可以只保留一个吗？

可以作为业务后处理，但那已经是去重规则。若目标是完整保留输入，不应在解析时自动删掉它；统计输入项数量时尤其要注意。

只要某个名称的全部值，必须保留完整列表吗？

不一定。若确实不需要全局顺序和其他字段，多值 map 就能满足查找。本文同时保留两种视图，是为了让调用方明确知道自己舍弃了什么。

ParseCookie 会自动选择正确的会话值吗？

不会。它解析 Cookie 头值并返回列表。多个同名值最终如何使用，需要由应用协议决定，不能仅凭返回列表中的位置证明其业务身份。

参考：Go http.ParseCookie 官方接口、Go Cookie 解析实现。样本与解析小工具为本文原创。