Go Cookie 为什么浏览器不保存

Go 服务调用了 http.SetCookie，浏览器却没有保存 Cookie，最常见的原因不是 Go 的 http.Cookie 结构体失效，而是响应头没有在响应提交前写出，或者 Cookie 属性与当前请求环境不匹配。排查时要分清三件事：浏览器有没有收到 Set-Cookie、收到后有没有接受并保存、后续请求是否满足发送条件。

先看响应头，再看属性，最后看后续请求。不要只在 Go 代码里确认“调用过 SetCookie”，因为调用发生了不等于浏览器接受了这条 Cookie。

本文围绕标准库 net/http 的服务端写法，重点解释响应时序、作用域、安全属性和最小可用 Handler。示例是静态说明，实际是否保存仍由浏览器按照请求 URL、站点关系和 Cookie 策略决定。

先确认响应真的写出了 Set-Cookie

http.SetCookie(w, cookie) 做的事情是把 Cookie 序列化到响应头。它必须发生在写状态码、写正文或调用可能提交响应头的操作之前。如果先调用 w.WriteHeader 或 w.Write，再补 Cookie，浏览器收到的响应里可能已经没有这条新的 Set-Cookie。

package main

import (
	"net/http"
)

func login(w http.ResponseWriter, r *http.Request) {
	// 先构造并写入响应 Cookie，再提交状态码和正文。
	http.SetCookie(w, &http.Cookie{
		Name:     "session_id",
		Value:    "demo-7f31",
		Path:     "/",
		HttpOnly: true,
		SameSite: http.SameSiteLaxMode,
	})

	// 写正文会让响应头进入提交流程，因此放在 SetCookie 之后。
	w.WriteHeader(http.StatusNoContent)
}

这里没有设置 Domain 和 Secure，是为了让示例先采用更窄的主机范围，并适合本地 HTTP 场景。若使用 HTTPS 生产环境，可以按实际部署域名增加 Secure: true；不要为了“让它保存”而随意写一个与当前响应主机无关的 Domain。

逐项检查 Cookie 属性

如果响应中确实有 Set-Cookie，下一步就检查属性。浏览器可能接受 Cookie，但它只会在匹配的请求上发送；也可能因为属性冲突、域名不合法或已经过期而直接不保存。

• Domain：省略时通常是只对当前主机生效的 host-only Cookie。设置 Domain 时，它必须是响应主机本身或其父域，不能写成无关域名或公共后缀。
• Path：决定后续请求路径是否匹配。登录接口若把 Path 设成 /login，访问 /api/user 时看不到它，并不代表浏览器没有保存。
• Secure：要求后续请求使用 HTTPS；本地 HTTP 调试时设置了它，常常会造成“已收到但后续不发送”的错觉。
• SameSite：Lax、Strict 和 None 控制跨站请求的发送范围。需要跨站发送时，SameSite=None 必须同时配合 Secure。
• MaxAge 与 Expires：零值和负值有删除语义；刚写入就设置了过期时间，也会表现为浏览器不保存。
• 前缀：__Host- 要求 HTTPS、Path=/ 且不能有 Domain；__Secure- 至少要求 Secure。前缀规则不满足时，浏览器会拒绝这条 Cookie。

另外，Cookie 的保存与 JavaScript 是否能读取是两件事。HttpOnly 会禁止脚本通过 document.cookie 读取，但不会阻止浏览器在满足条件的请求中携带 Cookie。因此，不能只看前端脚本读不到就判断“没有保存”。

用属性边界写出可保存的 Cookie

对于同主机的登录态，通常先从最小范围开始：省略 Domain，设置 Path=/，生产 HTTPS 使用 Secure，服务端会话 Cookie 使用 HttpOnly，并根据是否需要跨站请求选择 SameSite。下面这个 Handler 只表达属性关系，不依赖特定前端框架。

func setSession(w http.ResponseWriter, r *http.Request) {
	// host-only Cookie 不填写 Domain，避免把会话扩大到不需要的子域。
	cookie := &http.Cookie{
		Name:     "session_id",
		Value:    "opaque-session-value",
		Path:     "/",
		MaxAge:   3600,
		HttpOnly: true,
		Secure:   r.TLS != nil,
		SameSite: http.SameSiteLaxMode,
	}

	// SetCookie 必须位于任何正文写入之前。
	http.SetCookie(w, cookie)
	w.WriteHeader(http.StatusNoContent)
}

示例中的 r.TLS != nil 只适合应用直接终止 TLS 的简单场景。如果 HTTPS 在反向代理处终止，应用看到的连接可能仍是 HTTP，此时应根据可信的部署配置决定 Secure，而不是盲目相信客户端传来的普通请求头。

按接收、存储、发送三层排错

出现“浏览器不保存”时，可以按下面顺序缩小范围：

1. 接收层：确认实际响应头里存在 Set-Cookie，并检查是否在写状态码或正文后才调用 SetCookie。
2. 存储层：确认 Domain 属于当前响应主机，Path 覆盖目标路径，MaxAge/Expires 没有立即过期，Cookie 前缀和 Secure 约束没有冲突。
3. 发送层：确认后续请求使用 HTTPS、路径匹配，跨站场景的 SameSite 配置符合请求类型；如果是脚本发起请求，还要检查请求是否允许携带凭据。
4. 服务端读取层：Go 端用 r.Cookie("session_id") 或 r.Cookies() 读取请求中实际带回的 Cookie。读取不到时，先判断请求头是否携带，而不是回头怀疑 Cookie 结构体。

func currentSession(w http.ResponseWriter, r *http.Request) {
	cookie, err := r.Cookie("session_id")
	if err != nil {
		// ErrNoCookie 只说明当前请求没有带上该 Cookie。
		if err == http.ErrNoCookie {
			http.Error(w, "missing session cookie", http.StatusUnauthorized)
			return
		}
		// 其它解析错误也要停止继续使用不完整的会话信息。
		http.Error(w, "invalid cookie", http.StatusBadRequest)
		return
	}

	// 只把 Cookie 当作会话索引，真实身份仍应由服务端存储校验。
	w.Header().Set("Content-Type", "text/plain; charset=utf-8")
	_, _ = w.Write([]byte(cookie.Value))
}

这个顺序能避免几个常见误判：HttpOnly 导致脚本读不到不等于没有保存；Path 不匹配说明当前请求不发送，不等于存储失败；Secure 与 HTTP 测试环境冲突时，问题在发送条件而不是 Go 的序列化。

总结：先看 Set-Cookie，再看匹配规则

Go Cookie 为什么浏览器不保存，通常要从三层回答：响应有没有在提交前写出 Set-Cookie；浏览器是否因 Domain、Path、Secure、SameSite、过期时间或前缀规则拒绝；后续请求是否满足发送条件。把这三层分开后，问题一般能很快落到具体属性，而不是在 http.Cookie 与浏览器开发者工具之间来回猜。

相关问题：设置了 HttpOnly 为什么前端读不到？ 这是设计如此，HttpOnly 阻止脚本读取，但不阻止符合条件的 HTTP 请求携带。为什么浏览器显示有 Cookie，Go 却读不到？ 先看当前请求的 Cookie 头，再检查请求的主机、路径、协议和站点关系。跨域登录该怎么配？ 先明确是跨源还是跨站，再决定 SameSite、Secure、请求凭据与服务端 CORS 的组合，不能只改一个 Cookie 属性。