Go问答：http.Cookie SameSite跨站请求为什么没有带上 Cookie怎样完成一个可复用的最小示例

Go 服务端已经调用了 http.SetCookie，但浏览器发起跨站请求时仍然没有带上 Cookie，通常不是 Go 把 Cookie “吃掉”了，而是浏览器同时检查了 SameSite、Secure、HTTPS 和请求凭据四组条件。最容易踩坑的组合是：把 SameSite=None 写上了，却忘记 Secure；或者服务端设置正确，前端 fetch 没有使用 credentials。

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

这篇用一个很小的 Go 示例把链路拆开：先建立“Cookie 是否发送”的基线，再选择 SameSite 模式，最后补齐 HTTPS 和前端凭据。这样排查时可以知道究竟是 Cookie 属性、传输条件还是调用方式出了问题。

先看基线：Cookie 为什么没有随跨站请求发送

先不要把“跨域”和“跨站”混成一个概念。跨域主要描述源（协议、主机、端口）不同后，浏览器是否允许脚本读取响应；SameSite 判断的是请求是否来自不同的 site，以及 Cookie 是否可以随请求发送。两个页面可能跨域但仍属于同站，也可能请求没有触发 CORS，却因为 SameSite 被限制。

把问题拆成四个观察点会更快：

这张图是静态判断示意，帮助定位规则分叉，不代表某个浏览器开发者工具的实际截图。

Strict、Lax、None 到底怎么选

http.Cookie.SameSite 是 Go 对 Set-Cookie 属性的结构化表达。Go 当前文档列出四种模式：默认模式、Lax、Strict 和 None。真正影响跨站请求的，是浏览器收到序列化后的 SameSite=... 后如何执行限制。

如果业务确实要让跨站 fetch 带上会话 Cookie，通常要从 SameSite=None 开始排查，但这不是唯一条件。None 会放宽发送范围，应该只用于明确需要跨站的 Cookie，并配合 HTTPS、HttpOnly、合理的 Path 和服务端 CSRF 防护。

完整最小示例：Go 设置 Cookie，前端跨站调用

下面的服务端处理函数返回一个带有 SameSite=None、Secure 和 HttpOnly 的 Cookie。示例假定请求在 HTTPS 环境中到达；如果直接用普通 HTTP 访问，浏览器可能因为 Secure 条件不满足而不保存或不发送它。

package main

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

func issueSession(w http.ResponseWriter, r *http.Request) {
	// SameSite=None 表示业务明确需要跨站发送 Cookie。
	// Secure 要求浏览器只在 HTTPS 请求中携带它。
	http.SetCookie(w, &http.Cookie{
		Name:     "session_id",
		Value:    "demo-session",
		Path:     "/",
		MaxAge:   3600,
		HttpOnly: true,
		Secure:   true,
		SameSite: http.SameSiteNoneMode,
	})

	// 响应体只用于说明服务端已经完成 Set-Cookie。
	fmt.Fprintln(w, "session cookie issued")
}

func whoami(w http.ResponseWriter, r *http.Request) {
	// Cookie 方法只读取当前请求中已经附带的 Cookie。
	cookie, err := r.Cookie("session_id")
	if err != nil {
		http.Error(w, "session cookie missing", http.StatusUnauthorized)
		return
	}

	// 生产环境应在这里校验签名、过期时间和服务端会话状态。
	fmt.Fprintf(w, "session=%s at=%s", cookie.Value, time.Now().Format(time.RFC3339))
}

func main() {
	// 路由分别模拟“写入 Cookie”和“读取当前会话”两个动作。
	http.HandleFunc("/issue", issueSession)
	http.HandleFunc("/whoami", whoami)
	_ = http.ListenAndServe(":8443", nil) // 示例省略证书加载，部署时应使用 HTTPS。
}

前端调用方也要明确声明凭据模式。对于跨站 fetch，可以使用 credentials: "include"；仅设置服务端 Cookie 而不设置这一项，浏览器仍可能不把 Cookie 附带到请求中。

async function loadSession() {
  // 跨站 fetch 显式允许浏览器带上符合条件的 Cookie。
  const response = await fetch("https://api.example.test/whoami", {
    method: "GET",
    credentials: "include",
  });

  // 非 2xx 响应通常意味着 Cookie 未保存、未发送或服务端拒绝会话。
  if (!response.ok) {
    throw new Error(`session request failed: ${response.status}`);
  }

  // 读取服务端返回的会话结果，而不是尝试读取 HttpOnly Cookie。
  return response.text();
}

这段示例只演示条件链路，不代表可以把 example.test 当成真实接口地址。跨站部署时还要让服务端按实际 Origin 配置 CORS，并允许凭据请求；不能用通配符 Origin 代替明确的可信来源。

基线对照：把漏项定位到具体一层

可以按下面顺序对照，而不是一上来反复改 SameSite。每次只改一层，浏览器的 Cookie 面板和请求头就能帮助你判断变化来自哪里。

1. 先看 Set-Cookie：确认响应里确实有 SameSite=None; Secure，并检查 Path、Domain 是否覆盖目标请求。
2. 再看传输协议：如果 Cookie 带有 Secure，跨站使用时应通过 HTTPS；开发环境不要把“HTTP 下不发送”误判成 Go 配置失效。
3. 再看前端请求：跨站 fetch 使用 credentials: "include"；同源请求可使用默认模式，但不要把两种场景混为一谈。
4. 最后看服务端读取：用 r.Cookie 检查请求是否有 Cookie，再区分“浏览器没发”和“服务端会话校验失败”。

如果服务端只返回 401，而响应头没有显示 Cookie 被拒绝，问题可能已经进入会话签名、过期时间、Domain 或代理改写层。SameSite 只负责 Cookie 的跨站发送策略，不负责验证你的业务会话是否有效。

几个容易误判的边界

• SameSite 不是 CORS：CORS 决定脚本能否读取跨域响应，SameSite 影响 Cookie 是否随请求发送；二者经常同时出现，但职责不同。
• None 不是“无条件发送”：浏览器仍会检查 Secure、Domain、Path、过期时间以及请求的凭据模式。
• HttpOnly 不是“不发送”：它限制脚本通过 document.cookie 读取，但符合条件的网络请求仍可以携带该 Cookie。
• 跨端口不等于跨站：端口变化会影响源和 CORS，但 SameSite 的 site 判断要按浏览器的站点规则分析。
• 安全属性不能代替 CSRF 防护：跨站会话设计仍应结合 CSRF Token、Origin/Referer 检查和最小权限。

相关问题

为什么设置了 SameSite=None 还是没有 Cookie？

优先检查是否同时设置了 Secure，请求是否通过 HTTPS，前端 fetch 是否使用 credentials: "include"，以及 Cookie 的 Domain、Path 是否匹配目标 URL。

Go 的 SameSiteNoneMode 会自动帮我打开 Secure 吗？

不要依赖自动补齐。代码中应显式设置 Secure: true，并按部署环境使用 HTTPS。这样配置意图清楚，也更容易从响应头定位问题。

跨域请求一定要设置 credentials 吗？

需要 Cookie 凭据的跨域 fetch 通常要显式设置 credentials: "include"，同时服务端 CORS 要允许具体来源和凭据。只要读取公开响应而不带 Cookie，就不必为了跨域本身盲目开启凭据。

SameSite=None 适合所有登录 Cookie 吗？

不适合。只有确实需要跨站使用的 Cookie 才考虑 None；普通同站会话优先选择更收敛的策略，并配合 HttpOnly、Secure、合理的过期时间和服务端 CSRF 防护。

把问题记成一条排查链即可：先确认 Set-Cookie，再确认 Secure 与 HTTPS，接着确认 fetch credentials，最后区分 CORS、Domain/Path 和会话校验问题。这样修改 http.Cookie 时，每一步都有明确的判断依据。