Go http.Cookie SameSite 设置后浏览器为什么仍不发送

很多人看到响应里已经有 Set-Cookie，就以为下一次请求一定会带上 Cookie。实际上，http.Cookie 只是帮 Go 服务端把属性写进响应头；浏览器收到后还会根据当前页面、目标 URL、请求方式和凭据策略重新判断。SameSite 设置正确但请求头里仍没有 Cookie，通常不是 Go 没写进去，而是浏览器认为这次请求不满足发送条件。

排查时先看响应是否真的保存了 Cookie，再判断请求是同站还是跨站，最后核对 SameSite、Secure、credentials 和 Path。若是跨站 fetch，Lax 或 Strict 不能靠 credentials: include 强行放行。

本文示例使用 Go 标准库的 net/http，图中内容均为帮助理解结构的操作示意图，不是实际运行截图。

Go http.Cookie 的 SameSite 只写入响应属性

服务端可以这样设置 Cookie：

http.SetCookie(w, &http.Cookie{
    Name:     "sid",                         // 保存会话标识，生产环境不要写入敏感明文
    Value:    "demo-session",                // 示例值，实际应使用不可预测的会话 ID
    Path:     "/",                           // 让站点根路径下的请求都满足路径匹配
    HttpOnly: true,                           // 限制脚本读取，降低 XSS 直接窃取风险
    Secure:   true,                           // 仅在 HTTPS 请求中发送；本地调试需注意协议
    SameSite: http.SameSiteLaxMode,           // 限制跨站请求，适合多数普通登录场景
})

这段代码产生的是响应头，例如 Set-Cookie: sid=...; Path=/; HttpOnly; Secure; SameSite=Lax。Go 不负责替浏览器决定后续请求是否携带它。Strict 更严格，跨站上下文基本不发送；Lax 允许有限的顶层安全导航，但不会把普通跨站 fetch 当成同站请求；None 才表示允许跨站携带，不过必须同时有 Secure。

先分清同站、同源和跨站

SameSite 判断的是 site，不完全等同于 CORS 使用的 origin。协议、注册域和子域的组合会影响站点关系；而 origin 还会把端口纳入判断。因此，两个地址可能属于同站，却仍是跨源请求；这时浏览器可能允许 Cookie 规则通过，但前端 fetch 仍需要凭据和服务器 CORS 响应配合。

例如页面在 https://app.example.test，接口在 https://api.example.test。如果 Cookie 的 Domain、Path 和 SameSite 条件都满足，跨源请求还要显式携带凭据：

fetch("https://api.example.test/me", {
    credentials: "include", // 跨源 fetch 明确允许浏览器带上 Cookie
    headers: { "Accept": "application/json" }, // 只保留本次接口需要的请求头
})

服务端同时要返回匹配的 Access-Control-Allow-Origin 和 Access-Control-Allow-Credentials: true。但要注意，credentials: include 不是 SameSite 的覆盖开关；Cookie 为 Lax 或 Strict 时，跨站请求仍可能被浏览器过滤。

四个条件逐项检查发送失败

第一，看 Set-Cookie 是否被浏览器接受。SameSite=None 没有 Secure，或在不满足安全上下文的情况下设置，通常会被拒绝。第二，看请求协议；Cookie 带了 Secure 却通过普通 HTTP 访问时，不会随请求发送。

第三，看请求路径。若服务端没有显式设置 Path，浏览器会根据设置 Cookie 的 URL 推导默认路径；接口路径不匹配时，SameSite 再宽松也没有用。第四，看请求类型和来源：跨站的 POST、iframe、图片加载和普通 fetch 都不能按“点击链接跳转”来理解。

建议按下面的顺序取证：

1. 在开发者工具的 Network 中看登录响应的 Set-Cookie，确认没有被标记为 blocked。
2. 在 Application/Storage 的 Cookies 中看域、路径、Secure、HttpOnly、SameSite 和过期时间。
3. 再打开实际接口请求，检查 Request Headers 是否出现 Cookie；不要只看响应里的 Set-Cookie。

别把常见现象归咎于 SameSite

如果存储面板里根本没有这条 Cookie，优先查域名、过期时间和浏览器拒绝原因；如果存储存在但请求没有携带，再看请求上下文和 Path；如果请求已经带上而 Go 读取为空，才回到服务端检查名称、重复 Cookie 和解析逻辑。服务端读取时可以直接使用：

cookie, err := r.Cookie("sid") // 按名称读取请求中已发送的 Cookie
if err != nil {
    http.Error(w, "session cookie missing", http.StatusUnauthorized) // 缺失时明确返回鉴权失败
    return
}
_ = cookie.Value // 生产代码还应校验会话是否存在、是否过期

速记就是：Set-Cookie 证明服务端尝试设置，存储面板证明浏览器接受，Cookie 请求头才证明本次请求实际携带。三处不要混为一谈。

相关问题

SameSite=None 是否总要配 Secure？ 是。浏览器要求 None 配合 Secure，否则跨站 Cookie 通常不会被接受。

credentials: include 能解决 Lax 不发送吗？ 不能。它解决的是 fetch 的凭据发送意愿，不能覆盖 SameSite 对跨站请求的限制。

Cookie 已保存但 Go 的 r.Cookie 为空怎么办？ 先看 Network 请求头是否有 Cookie。没有就查浏览器条件；有但读取失败，再核对 Cookie 名称和重复名称。