Go问答：http.Cookie.String为什么没有输出所有属性

如果你把 http.Cookie 的字段全部填上，却发现 String() 返回的文本没有包含所有属性，通常不是 Go 丢了数据，而是 Cookie 的序列化目标不同。请求头里的 Cookie 只需要发送名称和值；响应头里的 Set-Cookie 才会携带 Path、Domain、Expires、SameSite 等属性。

官方文档：https://pkg.go.dev/net/http#Cookie.String

结论：http.Cookie.String 不是把结构体原样格式化。它会先判断 Cookie 名称是否合法，再根据用途选择请求 Cookie 或 Set-Cookie 的序列化规则；如果名称非法或接收者为空，结果可能就是空字符串。

同一个 Cookie 为什么会有两种输出

Cookie 结构同时服务于客户端请求和服务端响应，所以字段并不总是出现在同一条头里。客户端把 Cookie 放进请求时，协议语义是名称和值的键值对；服务端通过 Set-Cookie 下发时，才需要告诉浏览器路径、域、过期时间和安全属性。

因此，直接打印 c.String() 再拿它和完整的 Set-Cookie 预期字符串比较，容易把“目标头不同”误判成“字段没有生效”。真正要先确认的是：这段字符串最终要写入请求，还是要写入响应。

先排除空字符串的两个原因

官方文档明确说明，Cookie 指针为空或 Cookie 名称无效时，String 会返回空字符串。这个结果和网络连接、浏览器策略没有直接关系，应该在构造头部以前处理。

package main

import (
	"fmt"
	"net/http"
)

func printCookie(c *http.Cookie) {
	if c == nil {
		// 空指针没有可序列化的名称和值，先在调用边界返回。
		fmt.Println("cookie is nil")
		return
	}

	value := c.String()
	if value == "" {
		// 空字符串优先检查 Name 是否为空或包含非法字符。
		fmt.Printf("cookie %q cannot be serialized\n", c.Name)
		return
	}

	// String 的结果只是头部值文本，最终仍要写入正确的请求或响应位置。
	fmt.Println(value)
}

func main() {
	printCookie(&http.Cookie{Name: "session_id", Value: "abc"})
	printCookie(&http.Cookie{Name: "bad name", Value: "abc"})
}

这段代码的重点不是依靠返回文本猜测原因，而是把空指针、名称合法性和头部写入位置分开。生产日志中可以记录名称是否通过校验，但不要把 Cookie 值直接写入普通日志。

请求 Cookie 只保留名称和值

当 Cookie 被放进客户端请求时，应该通过请求对象的 API 让 net/http 负责放置头部。不要把面向响应的属性字符串直接拼进 Cookie 请求头，否则读者会看到“字段写了但服务端没有按预期解析”的现象。

package main

import (
	"fmt"
	"net/http"
)

func requestWithCookie() (*http.Request, error) {
	req, err := http.NewRequest(http.MethodGet, "https://example.com/profile", nil)
	if err != nil {
		// 构造请求失败时把原始错误交给上层，不伪造 Cookie 已经发送。
		return nil, fmt.Errorf("create request: %w", err)
	}

	c := &http.Cookie{
		Name:     "session_id",
		Value:    "abc123",
		Path:     "/profile", // Path 是响应属性，不会按请求 Cookie 属性发出。
		HttpOnly: true,        // HttpOnly 同样属于 Set-Cookie 语义。
	}
	req.AddCookie(c)

	// AddCookie 会把名称和值放入 Cookie 请求头，避免手写分隔符和属性。
	return req, nil
}

这里保留 Path 和 HttpOnly 是为了说明结构体可以承载完整的 Cookie 状态，但它们不是请求头 Cookie 的发送属性。若要观察请求头，应看 req.Header.Get("Cookie")；若要生成响应头，则使用下面的响应路径。

响应 Set-Cookie 才是属性完整输出的位置

服务端要下发 Cookie 时，直接调用 http.SetCookie，它会把序列化结果写入响应头。与请求头不同，此时路径、过期时间、Secure、HttpOnly 和 SameSite 才有明确的响应语义。

package main

import (
	"net/http"
)

func handler(w http.ResponseWriter, _ *http.Request) {
	c := &http.Cookie{
		Name:     "session_id",
		Value:    "abc123",
		Path:     "/",
		HttpOnly: true,
		Secure:   true,
		SameSite: http.SameSiteLaxMode,
	}

	// SetCookie 面向 Set-Cookie 响应头，属性是否出现由响应序列化规则决定。
	http.SetCookie(w, c)
	w.WriteHeader(http.StatusNoContent)
}

如果只调用 c.String() 并打印到终端，它不会替代响应写入动作；如果在响应已经写出后才修改 Cookie，也不会改变客户端已经收到的头部。调试时要同时检查生成字符串和写入响应的时机。

Unparsed 不是任意追加 Set-Cookie 属性的入口

Cookie 还包含 Raw、RawExpires 和 Unparsed 等字段。它们主要服务于解析或保留无法按结构化字段表达的信息，不应被当成“把任意文本追加到 String() 结果”的通用接口。需要自定义属性时，应先确认 Go 当前版本的标准库是否提供对应字段，并按合法的响应头流程处理。

尤其要区分两个方向：解析已有 Set-Cookie 时，解析器可能把不认识的片段记录下来；重新序列化时，标准库仍会按照 Cookie 头部规则过滤和组织字段。把 Unparsed 当成原始字符串拼接区，会让输出看似完整，却不一定符合接收方的解析规则。

按三层顺序定位“属性没输出”

1. 确认目标头。请求头只验证名称和值；响应头才验证路径、域、过期时间和安全属性。
2. 确认名称合法。名称为空、包含空白或不符合 Cookie 名称要求时，先修复输入，不要追查网络。
3. 确认写入时机。响应头必须在正文或状态写出前设置；请求头应通过 AddCookie 或明确的 Header API 添加。
4. 确认字段语义。结构体字段存在不代表它会出现在每一种头部；以官方 Cookie.String 文档的目标头说明为准。

小结

http.Cookie.String 的输出取决于 Cookie 是否有效，以及它要服务的 HTTP 头部语义。请求路径用 AddCookie，重点是名称和值；响应路径用 http.SetCookie，再检查属性和写入时机。遇到字段缺失时，先按“目标头、名称合法性、写入时机”三层排查，不要把结构体字段和最终文本做机械一一对应。

相关问题

• 为什么设置了 Path，客户端请求里的 Cookie 仍然没有 Path？因为 Path 是 Set-Cookie 响应属性，不属于 Cookie 请求头的键值格式。
• Cookie 名称不合法时会发生什么？String() 可能返回空字符串；应在构造阶段修复名称，而不是继续拼接头部。
• 能否直接拼接 Cookie 字符串？简单场景可以观察格式，但真实请求和响应应优先使用 AddCookie 与 SetCookie，减少分隔符和属性语义错误。
• 为什么响应头设置后仍看不到 Cookie？检查是否在响应状态或正文写出之后才调用设置逻辑，以及是否把响应头误看成请求头。