Go http.Cookie 的 SameSite 为什么影响跨站请求

做第三方登录或前后端分域部署时，Go 服务端明明已经写出了 Cookie，回调接口却没有收到登录态。先记住一个边界：http.Cookie 负责把属性写进 Set-Cookie，后续是否在跨站请求中带上 Cookie 请求头，主要由浏览器按照 SameSite、协议、域名和请求类型判断。

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

先分清 Go 写入 Cookie 和浏览器发送 Cookie

Go 处理的是 HTTP 报文。服务端调用 http.SetCookie 后，浏览器收到的是一个 Set-Cookie 响应头；浏览器是否保存、以及下一次请求是否带上它，不由 http.SetCookie 再次决定。

func login(w http.ResponseWriter, r *http.Request) {
    // SameSite 属性会被序列化到 Set-Cookie，浏览器再按它判断跨站发送。
    cookie := &http.Cookie{
        Name:     "session",
        Value:    "demo-session",
        Path:     "/",
        HttpOnly: true,
        Secure:   true,
        SameSite: http.SameSiteNoneMode,
    }
    http.SetCookie(w, cookie)
    w.WriteHeader(http.StatusNoContent)
}

因此“服务端设置成功”只说明响应头里有候选 Cookie，不等于跨站接口一定会收到它。若前端通过跨站 fetch 调用接口，还要让请求带凭据，并让服务端返回匹配的 CORS 凭据响应；这与 SameSite 是两层条件。

Strict、Lax、None 应该怎么选

Go 在 net/http 中提供 SameSiteDefaultMode、SameSiteLaxMode、SameSiteStrictMode 和 SameSiteNoneMode。它们表达的是服务器希望浏览器采用的 Cookie 属性，真正的跨站行为仍要按浏览器规则判断。

最容易误判的是 Lax：它不是“允许跨站”，而是只放宽了有限的顶层导航场景。若业务是跨站 POST、XHR 或 fetch，不要因为页面能打开就推断 Cookie 一定会发送。

在 Go 中把属性组合写完整

如果确实需要跨站会话，SameSite=None 与 Secure=true 要成对出现。HttpOnly 控制脚本能否读取 Cookie，Path 控制请求路径范围，它们不能替代 SameSite，也不能修复不匹配的站点关系。

func issueCrossSiteSession(w http.ResponseWriter) {
    // None 用于确需跨站携带的会话；Secure 要求通过 HTTPS 发送。
    http.SetCookie(w, &http.Cookie{
        Name:     "session",
        Value:    "demo-session",
        Path:     "/",
        HttpOnly: true,  // 降低脚本直接读取会话值的风险。
        Secure:   true,  // 生产环境使用 HTTPS，避免明文传输。
        SameSite: http.SameSiteNoneMode,
    })
}

func readSession(r *http.Request) (string, error) {
    // 这里只读取已经到达服务端的 Cookie，不负责判断浏览器为何没有发送。
    cookie, err := r.Cookie("session")
    if err != nil {
        return "", err
    }
    return cookie.Value, nil
}

如果只是同站应用，优先从 Lax 或 Strict 开始；不要为了绕过一次跨域失败就统一改成 None。跨站放行后，还要针对登录回调、状态参数、CSRF Token 和来源校验建立自己的防护。

登录失败时按四层线索排查

第一层看响应头：确认 Set-Cookie 是否包含预期的 SameSite、Secure、Domain 和 Path。第二层看浏览器实际发出的请求：没有 Cookie 时，继续核对它是不是跨站、是否为顶层导航、请求方法是否安全。

第三层看协议和域名：Secure Cookie 不能依赖普通 HTTP；Domain 只决定可覆盖的主机范围，Path 只决定路径范围，它们都不会把一个被 SameSite 拒绝的跨站请求变成允许。第四层再看 CORS：跨站脚本请求通常需要客户端显式带凭据，服务端也不能用通配来源配合凭据响应。

常见问题

为什么 Go 已经返回 Set-Cookie，下一次请求仍然没有 Cookie？

Set-Cookie 只是服务端给出的属性集合。浏览器还会检查 SameSite、Secure、Domain、Path、过期时间以及请求是否带凭据，任何一层不满足都可能不发送。

跨站登录回调一定要用 SameSite=None 吗？

不一定。若只是外站顶层导航回到本站，Lax 可能足够；如果是跨站接口、嵌入页面或必须在跨站写请求中携带会话，才考虑 None，并同时使用 Secure 和 CSRF 防护。

SameSite 能解决所有跨站认证问题吗？

不能。它只处理 Cookie 的跨站发送边界。还要分别检查 CORS 凭据、Origin 校验、Domain、Path、HTTPS、会话过期和服务端读取逻辑。