Go http.Cookie 为什么在边界输入上得到空结果

在 Go 里看到 http.Cookie 的结果为空，先不要把原因归结为 Cookie 值丢失。最常见的情况是调用 Cookie.String() 时对象为 nil，或者 Name 不是合法的 HTTP token；如果问题来自请求头，则还可能是没有 Cookie 头、片段格式不合法，或请求中的 Cookie 数量超过限制。

这几类“空结果”对应的 API 和排查方式不同：String() 返回空字符串，Valid() 返回具体错误，ParseCookie() 返回错误，而 Request.Cookies() 在部分解析边界下只能给出空切片。把返回类型先分清，定位会快很多。

先确认空结果来自哪个 API

Cookie.String 为什么会直接返回空字符串

String() 的空字符串条件很窄：接收者是 nil，或 Name 不能通过合法 token 判断。合法的名称通常由字母、数字和允许的标点组成，不能把空名称、带空格的名称或带控制字符的名称当作普通字段使用。

package main

import (
	"fmt"
	"net/http"
)

func main() {
	var empty *http.Cookie
	invalid := &http.Cookie{Name: "user id", Value: "42"}
	valid := &http.Cookie{Name: "user_id", Value: "42"}

	// nil 接收者和非法 Name 都会让 String 返回空字符串。
	fmt.Printf("nil=%q invalid=%q valid=%q\n", empty.String(), invalid.String(), valid.String())
}

这里要注意，空字符串不是“Cookie 的 Value 为空”。Name="user_id", Value="" 仍然可以序列化为 user_id=；真正让整个序列化结果为空的是接收者或名称这一层的失败。

Value、Path 和 Domain 出问题时不一定得到空字符串

名称通过检查后，String() 会继续拼接名称、等号和值以及可选属性。Value 中不允许出现在 Cookie 头里的字节可能被清洗，非法的 Path 字节也可能被丢弃并记录日志；非法 Domain 则会被丢弃 Domain 属性，Cookie 仍可能退化为 host-only Cookie。

如果业务需要“完全合法”的 Cookie，不要只检查 String() != ""，而应该调用 Valid()，因为 String() 的目标是生成可发送的字符串，不是把所有字段错误都变成调用失败。

func serializeCookie(c *http.Cookie) (string, error) {
	// 先返回可定位的字段错误，避免把被清洗后的字符串当成原始值。
	if err := c.Valid(); err != nil {
		return "", fmt.Errorf("cookie 无效: %w", err)
	}

	value := c.String()
	if value == "" {
		// 这一分支主要覆盖 nil 或非法 Name，作为防御性保护。
		return "", fmt.Errorf("cookie 序列化为空")
	}
	return value, nil
}

Valid() 还能把 nil、非法 Name、非法 Value、非法 Path、非法 Domain 以及不满足约束的 Partitioned Cookie 区分开。对外部输入创建 Cookie 时，这个错误比单纯打印空字符串更有诊断价值。

请求头解析为什么会得到空切片

如果调用的是 r.Cookies()，它处理的是请求头，而不是某个已经创建好的 Cookie 对象。没有 Cookie 头时，返回空切片是正常结果；请求头中的坏片段也可能被跳过，因此不能只用切片长度判断“服务器完全没有收到 Cookie”。

还要留意数量边界。Go 的 HTTP Cookie 解析器会统计头中以分号分隔的片段数量；超过默认上限时，读取请求 Cookie 的内部路径会以空切片结束。这种情况下，应用层看到的不是一个具体解析错误，而是“没有解析出 Cookie”，所以日志中应同时保留原始头的数量统计，避免误判为客户端没有携带状态。

func readSession(r *http.Request) (string, error) {
	cookies := r.Cookies()
	for _, c := range cookies {
		// 只按名称选择业务 Cookie，避免把空集合误当成解析成功。
		if c.Name == "session_id" {
			return c.Value, nil
		}
	}

	// 没有目标 Cookie 时返回业务错误，和“值本身为空”分开处理。
	return "", fmt.Errorf("请求中没有 session_id Cookie")
}

需要保留解析错误时，可以对原始 Header 调用 http.ParseCookie。它的行为更适合输入校验：缺少等号、名称非法或值格式非法时会返回错误，而不是静默跳过全部上下文。

把三类边界放进排查顺序

1. 先看变量类型：确认拿到的是空字符串、nil 指针、错误还是空切片。
2. 对 Cookie.String() 检查指针和 Name，不要先盯着 Value。
3. 对需要严格发送的对象调用 Valid()，记录具体字段错误。
4. 对请求读取检查 Cookie 头是否存在，再区分坏片段与数量边界。
5. 将“没有 Cookie”“Cookie 值为空”“Cookie 解析失败”映射成不同的业务日志和响应。

常见误区与结论

• 误区：String() == "" 代表 Value 为空。
  实际：优先检查 nil 接收者和非法 Name。
• 误区：r.Cookies() 为空就说明客户端没发头。
  实际：还可能是坏片段被跳过或 Cookie 数量达到限制。
• 误区：String 生成了文本就代表所有字段都合法。
  实际：需要严格校验时应使用 Valid()。

相关问题

Cookie 的 Value 为空还能发送吗？可以，合法名称配合空值仍能形成名称加等号的序列化结果。

为什么 ParseCookie 和 Request.Cookies 的表现不一样？前者面向显式输入校验，返回错误；后者面向请求读取，部分不合法片段会被忽略。

排查 Cookie 时最应该记录什么？记录调用 API、Cookie 头是否存在、片段数量、目标名称和 Valid() 的具体错误，不要只记录最终空字符串。