Go 设置 Cookie 后浏览器为什么不带？SameSite、Secure 和跨站请求排查

Go 接口已经返回 Set-Cookie，但浏览器下一次请求仍然不带 Cookie，常见原因不是 http.SetCookie 没生效，而是浏览器根据 SameSite、Secure、Domain、Path 和跨站请求规则把 Cookie 拦下了。排查时要把后端响应头、浏览器存储状态、下一次请求头和前端请求配置放在一起看；只看 Go 代码，很容易漏掉浏览器策略这一层。

问题现场：Set-Cookie 有返回，下一次请求却没有 Cookie

最典型的现场是登录接口返回 200，Network 里能看到响应头带着 Set-Cookie，可随后请求 /api/profile、/api/user 或业务接口时，Request Headers 里没有 Cookie，服务端继续返回 401。这个时候先不要急着改 Session 读取逻辑，应该先确认浏览器有没有接受这个 Cookie。

浏览器先决定 Cookie 能不能被保存和发送

http.SetCookie 的职责是把 Set-Cookie 写进响应头。浏览器收到响应后，还会按自己的安全策略判断是否保存、何时发送。MDN 对 Set-Cookie 的说明里明确列出 SameSite、Secure、HttpOnly、Domain、Path 等属性；Go 的 net/http 文档也把这些字段放在 http.Cookie 结构体里。

这里最容易混淆的是“同站”和“跨站”。页面在 https://app.example.com，接口在 https://api.example.com，很多团队会觉得它们只是两个子域；但浏览器判断 Cookie 发送时，还会结合站点、协议、请求方式和 Cookie 属性。更复杂的是，前端 fetch 默认不会把跨站凭据自动带上，后端 CORS 也不能用通配符简单放行。

Go 里设置 Cookie：字段写对只是第一步

Go 里设置 Cookie 可以用 http.SetCookie。如果是线上 HTTPS、前后端确实跨站并且必须用 Cookie 维持登录态，可以先从下面这个最小配置开始，再结合业务域名收紧范围。

func loginHandler(w http.ResponseWriter, r *http.Request) {
    sessionID := "session-abc123"

    http.SetCookie(w, &http.Cookie{
        Name:     "sid",
        Value:    sessionID,
        Path:     "/",
        HttpOnly: true,
        Secure:   true,
        SameSite: http.SameSiteNoneMode,
        MaxAge:   3600,
    })

    w.WriteHeader(http.StatusNoContent)
}

如果你的页面和接口是同站访问，SameSite=Lax 往往更适合普通登录态，因为它比 None 更收敛。只有在独立前端域名、第三方嵌入、跨站接口调用等确实需要跨站携带 Cookie 的场景，才应该考虑 SameSite=None，并同时启用 Secure。

http.SetCookie(w, &http.Cookie{
    Name:     "sid",
    Value:    "session-abc123",
    Path:     "/",
    HttpOnly: true,
    Secure:   true,
    SameSite: http.SameSiteLaxMode,
})

跨站请求：SameSite、Secure 和 credentials 要一起对齐

跨站 Cookie 排查最怕只改其中一边。后端设置了 SameSite=None; Secure，前端没开凭据，请求仍然不会带 Cookie；前端开了 credentials，后端 CORS 用了 *，浏览器也不会按带凭据请求处理。要让链路闭合，至少要同时核对三层：Go Cookie、浏览器策略、前端请求。

1. 前端请求要允许携带凭据

fetch("https://api.example.com/me", {
  method: "GET",
  credentials: "include"
})

如果使用 Axios，则对应配置是 withCredentials。

axios.get("https://api.example.com/me", {
  withCredentials: true
})

2. Go 服务端 CORS 不能用通配符糊过去

func withCORS(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        origin := r.Header.Get("Origin")
        if origin == "https://app.example.com" {
            w.Header().Set("Access-Control-Allow-Origin", origin)
            w.Header().Set("Access-Control-Allow-Credentials", "true")
            w.Header().Set("Vary", "Origin")
        }

        if r.Method == http.MethodOptions {
            w.Header().Set("Access-Control-Allow-Headers", "Content-Type")
            w.Header().Set("Access-Control-Allow-Methods", "GET,POST,OPTIONS")
            w.WriteHeader(http.StatusNoContent)
            return
        }

        next.ServeHTTP(w, r)
    })
}

带凭据的跨站请求应该返回具体来源，例如 https://app.example.com，不要返回 Access-Control-Allow-Origin: *。同时加上 Vary: Origin，可以避免缓存层把一个来源的响应头错误复用到另一个来源。

本地、子域和反向代理下的兼容处理

很多“线上才出问题”的 Cookie 故障，实际出在环境差异。本地是 HTTP，线上是 HTTPS；本地页面和接口都在 localhost，线上变成两个域名；服务端认为自己收到的是 HTTP，但外层 Nginx 或负载均衡已经终止了 TLS。环境一变，Secure、Domain 和回源协议都会影响结果。

• 本地 HTTP：如果 Cookie 配了 Secure，普通 HTTP 调试时可能看不到同样效果。可以用本地 HTTPS，或者把本地策略和线上策略明确区分。
• 子域共享：需要让 app.example.com 和 api.example.com 共享 Cookie 时，再考虑 Domain=.example.com；不需要共享时，尽量让 Cookie 只绑定设置它的主机。
• 反向代理：如果 Go 根据请求协议决定是否设置 Secure，要确认代理是否传递了 X-Forwarded-Proto，并且应用层是否信任这类头。
• 路径覆盖：Path=/api 只能覆盖对应路径，访问 /me 或 /profile 时不一定会带。登录态 Cookie 通常用 Path=/ 更容易理解。

安全边界：不要为了带上 Cookie 过度放宽

把 Cookie 带上只是目标之一，真正上线还要兼顾安全边界。跨站 Cookie 越宽，越要把来源白名单、CSRF 防护、登录态过期、退出登录清理和敏感操作二次校验做扎实。HttpOnly 可以降低前端脚本直接读取 Cookie 的风险，但它不会阻止浏览器按规则自动发送 Cookie；需要防跨站提交时，仍要配合 CSRF Token、Origin 校验或更严格的 SameSite 策略。

如果只是同站后台、管理系统或普通用户中心，不要为了“以后可能跨域”就默认上 SameSite=None。更推荐先用较收敛的策略跑通，再为确实存在的跨站入口单独验证。

相关问题

Go 设置 SameSite=None 为什么本地 HTTP 不稳定？

SameSite=None 通常要和 Secure 一起使用，而 Secure 依赖安全上下文。本地如果只用普通 HTTP，就很容易和线上 HTTPS 表现不同。联调登录态时，最好准备本地 HTTPS 或一套接近线上的测试域名。

Access-Control-Allow-Origin 可以写星号吗？

普通无凭据跨站请求可以用通配符，但要携带 Cookie 时不适合。带凭据请求应返回具体来源，并设置 Access-Control-Allow-Credentials: true。

HttpOnly 会不会导致浏览器不带 Cookie？

不会。HttpOnly 主要限制 JavaScript 读取 Cookie，浏览器仍会按 SameSite、Secure、Domain、Path 等规则发送。

Domain 不写是不是更安全？

通常是的。不写 Domain 时，Cookie 绑定到设置它的主机，范围更小。如果确实需要多个子域共享，再谨慎设置 Domain=.example.com。

总结

Go 设置 Cookie 后浏览器不带，排查重点不是“语法有没有写对”，而是整条链路有没有对齐：响应里是否有 Set-Cookie，浏览器是否保存，下一次请求是否带上，前端是否允许凭据，CORS 是否返回具体来源，Cookie 的 SameSite、Secure、Domain 和 Path 是否覆盖实际访问方式。按这个顺序查，比反复改登录判断更快，也更容易把线上问题讲清楚。