Go问答：http.Cookie SameSite跨站请求为什么没有带上 Cookie为什么结果为空或不符合预期

当 Go 服务端用 http.Cookie 写入会话 Cookie 后，跨站请求却拿不到它，问题通常不在 r.Cookie() 这一行，而在浏览器是否愿意把 Cookie 放进请求。Go 负责生成 Set-Cookie、读取到达服务端的 Cookie 头；SameSite、HTTPS、前端凭据模式和 CORS 共同决定跨站请求能否完成。

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

先看 Go 生成的 Set-Cookie 是否完整

Go 的 SameSite 是 Cookie 的序列化属性，不是浏览器发送策略的替代品。先在登录或建立会话的响应里确认它真的出现，再判断跨站场景是否符合预期：

package main

import "net/http"

func setSession(w http.ResponseWriter, value string) {
	// SameSite=None 允许跨站请求使用，但必须配合 HTTPS 的 Secure。
	http.SetCookie(w, &http.Cookie{
		Name:     "session_id",
		Value:    value,
		Path:     "/",
		HttpOnly: true, // 阻止脚本读取会话值，仍可由浏览器自动发送。
		Secure:   true, // 生产环境只在 HTTPS 连接上传输。
		SameSite: http.SameSiteNoneMode,
	})
}

如果业务只是同站页面之间的登录态，优先使用 http.SameSiteLaxMode；需要更严格限制时使用 Strict。不要为了让请求“先通起来”就无条件改成 None。

Strict、Lax 和 None 的发送边界不同

Strict 只面向同站请求；Lax 通常允许从其他站点进入本站的顶层安全导航，但不适合跨站 fetch、iframe 或多数 POST 请求；None 才表示允许跨站发送，而且必须同时带 Secure。因此，“响应里看到了 Set-Cookie”只能说明 Cookie 曾被设置，不能证明下一次跨站 API 请求一定会携带它。

credentials: include 仍然不能绕过 SameSite

跨源前端请求常见写法如下。它解决的是 Fetch 默认只携带同源凭据的问题；如果 Cookie 是 Lax 或 Strict，浏览器仍可能因为跨站条件而不发送。

const response = await fetch("https://api.example.test/profile", {
  // 允许浏览器在跨源请求中考虑 Cookie，并非强制绕过 SameSite。
  credentials: "include"
});

服务端必须对可信来源返回具体的 Access-Control-Allow-Origin，并返回 Access-Control-Allow-Credentials: true；带凭据时不能把允许来源写成通配符 *。CORS 通过后，仍要满足 Cookie 自身的 SameSite、Domain、Path 和 Secure 条件。

用 Go 入口日志区分“没发送”和“没读取”

不要只记录业务层拿到的用户 ID。先在请求入口检查 Cookie 是否到达，再看具体 Cookie 名称和错误：

func profile(w http.ResponseWriter, r *http.Request) {
	c, err := r.Cookie("session_id")
	if err != nil {
		// ErrNoCookie 只说明当前请求没有这个 Cookie，不等于登录接口没设置成功。
		if err == http.ErrNoCookie {
			http.Error(w, "session cookie missing", http.StatusUnauthorized)
			return
		}
		http.Error(w, "invalid cookie", http.StatusBadRequest)
		return
	}

	// 业务代码只使用已到达请求的值，避免把缺失误判为 SameSite 的唯一原因。
	_ = c.Value
	w.WriteHeader(http.StatusNoContent)
}

若浏览器 Network 面板里请求没有 Cookie 头，优先查浏览器策略和 Cookie 属性；若请求已有头但 Go 返回 ErrNoCookie，再查名称、格式或代理层是否改写。还要核对 Path 是否覆盖接口路径、Domain 是否属于当前主机，以及 Secure 与协议是否匹配。

一张排查清单：按层验证，不要只改 SameSite

1. 看登录响应的 Set-Cookie：属性是否完整，浏览器是否接受。
2. 看后续请求的 URL、顶层站点、方法和请求类型：是同站、跨站导航，还是跨站 API。
3. 看前端是否使用 credentials: "include"，服务端是否返回明确 CORS 允许来源和凭据标志。
4. 看请求是否真的带 Cookie 头，再在 Go 中用 r.Cookie 或 r.Cookies 读取。
5. 按最小权限选择配置：普通登录态先用 Lax；只有确实需要跨站使用时才考虑 None + Secure，并补齐 CSRF 防护。

常见问题

为什么设置了 credentials: include 还是没有 Cookie？

因为它只改变 Fetch 的凭据参与方式，不能突破 SameSite、Secure、Domain、Path 或浏览器第三方 Cookie 限制。先确认 Cookie 是否是 None + Secure，以及请求是否真的跨站。

Go 的 SameSiteDefaultMode 能保证跨站行为一致吗？

不能。默认模式表示不显式写出 SameSite，实际默认行为由浏览器决定。需要稳定边界时应根据业务明确选择 Lax、Strict 或 None。

看到服务端没有 Cookie，应该先改 CORS 吗？

不一定。先看浏览器发出的请求是否含 Cookie；没有的话先查 SameSite、Secure、Domain 和 Path，只有请求已带凭据但浏览器阻止跨源响应时再处理 CORS。