Go http.Request.Cookie 未找到时怎样判断缺失和空值

在 Go 的 HTTP 处理器里，r.Cookie("session_id") 查不到目标 Cookie 时，正确判断依据是返回的错误：http.ErrNoCookie。如果 Cookie 确实存在，即使它的 Value 是空字符串，也会先得到一个非 nil 的 *http.Cookie。所以不要只判断指针，更不要把空值直接当成缺失。

官方资料：https://pkg.go.dev/net/http#Request.Cookie

先看 Request.Cookie 的返回契约

Request.Cookie 的签名是 (*http.Cookie, error)。官方实现会先处理空名称，再遍历请求中的 Cookie；名称为空或没有匹配项时返回 http.ErrNoCookie。找到匹配项时返回一个 Cookie 指针和 nil 错误。这个契约已经把“有没有这项”与“这项的值是什么”分开了。

因此，缺失场景不要写成 cookie == nil 的单层猜测。更稳妥的做法是先处理错误，再把其他错误与“没有这个 Cookie”分开，最后才读取值。

按错误、指针、Value 三层读取

下面这个小函数把请求入口常见的四种结果分开：没有 Cookie、读取过程出现其他错误、Cookie 存在但值为空、Cookie 存在且有值。示例使用 errors.Is，这样即使上层对错误做了包装，判断仍然清楚。

package main

import (
    "errors"
    "fmt"
    "net/http"
)

func sessionState(r *http.Request) string {
    // 先判断查找错误，不用空指针或 Value 猜测“是否存在”。
    cookie, err := r.Cookie("session_id")
    if errors.Is(err, http.ErrNoCookie) {
        return "缺失"
    }
    if err != nil {
        // 其他错误要保留，避免把异常请求伪装成匿名请求。
        return fmt.Sprintf("读取失败：%v", err)
    }

    // 无错误时 cookie 已经存在，空 Value 是一个独立业务状态。
    if cookie.Value == "" {
        return "存在但值为空"
    }
    return "存在且有值"
}

生产代码里，空值到底代表“未登录”“客户端清空了会话”还是“允许匿名”，应由业务协议决定。技术层面只负责把状态区分出来，不能因为看到空字符串就擅自改成缺失。

用一个请求构造出“缺失”和“空值”

测试这类逻辑时，关键是同时准备两个请求：一个完全没有目标 Cookie，另一个明确带有同名但空值的 Cookie。这样能验证判断顺序，而不是只覆盖“有正常值”的 happy path。

func makeCookieRequests() (*http.Request, *http.Request) {
    missing := httptest.NewRequest(http.MethodGet, "http://example.test/", nil)

    empty := httptest.NewRequest(http.MethodGet, "http://example.test/", nil)
    // 显式添加空值 Cookie，用来证明“存在”和“有值”不是同一件事。
    empty.AddCookie(&http.Cookie{Name: "session_id", Value: ""})
    return missing, empty
}

func inspect(r *http.Request) string {
    // ErrNoCookie 只代表没有匹配项，不能替代对 Value 的判断。
    c, err := r.Cookie("session_id")
    if errors.Is(err, http.ErrNoCookie) {
        return "missing"
    }
    if err != nil {
        return "error"
    }
    if c.Value == "" {
        return "present-empty"
    }
    return "present-value"
}

上面的代码片段需要额外导入 net/http/httptest。它是测试数据构造方式，不代表线上请求一定来自测试服务器；图示与代码的重点是 Cookie 状态边界。

处理同名 Cookie：Request.Cookie 与 CookiesNamed 的选择

如果请求里有多个同名 Cookie，Request.Cookie 的契约是只返回一个匹配项。只需要一个会话标识时，这个接口足够；如果业务必须看到所有匹配项，就应该改用 Request.CookiesNamed，再明确排序、优先级或冲突策略。

func readCookieCandidates(r *http.Request) []*http.Cookie {
    // 需要审计重复值时返回列表，不把单个结果误当成全部结果。
    return r.CookiesNamed("session_id")
}

func readOneCookie(r *http.Request) (*http.Cookie, error) {
    // 只接受一个会话 Cookie 时，让 Request.Cookie 表达这个意图。
    return r.Cookie("session_id")
}

两种接口没有谁“更正确”：前者表达“取一个”，后者表达“收集全部”。不要通过反复调用 Request.Cookie 来猜测重复项，那仍然只是在重复读取同一个单值契约。

请求入口的推荐处理流程

1. 先确定 Cookie 名称是否来自固定协议；不接受空名称或未经约束的外部字段。
2. 调用 Request.Cookie 后先处理 http.ErrNoCookie，再处理其他错误。
3. 拿到 Cookie 指针后再判断 Value 是否为空，并映射到明确的业务状态。
4. 只有确实需要处理重复值时，才改用 CookiesNamed，并写出冲突决策。

常见误区有两个：把 Value == "" 当成 Cookie 缺失，以及把 Request.Cookie 的单个返回当成请求中全部同名 Cookie。前者会吞掉客户端主动清空值的语义，后者会让排障日志缺少重复项信息。

常见问题

Cookie 不存在时，应该判断 error 还是 cookie 指针？

优先判断 error，用 errors.Is(err, http.ErrNoCookie) 表示“没有匹配项”。指针是否为 nil 是返回结果的一部分，但不是最有表达力的缺失契约。

Cookie 存在但 Value 为空，算不算缺失？

不算。它是“找到 Cookie，但值为空”的状态。是否把它当成未登录，要由业务规则决定，技术代码应先保留这个区别。

什么时候应该使用 CookiesNamed？

当重复 Cookie 本身具有业务意义，或你需要记录并处理所有候选值时使用。只需要一个明确会话标识时，Request.Cookie 更直接。

总结：Go 的 http.Request.Cookie 查找不到目标项时返回 http.ErrNoCookie；查到一个空值 Cookie 时仍返回 Cookie 指针。把判断顺序固定为“错误 → 指针 → Value”，再根据是否需要重复项选择单值或列表接口，Cookie 入口逻辑就不会把缺失、空值和异常混成一类。