SameSite属性必须由服务端在Set-Cookie响应头中显式设置，Gin默认不设且http.SameSiteDefaultMode等效于未声明，无法防CSRF；需手动传入http.SameSiteLaxMode等整型常量，并配合Secure、Domain等字段正确配置。
SameSite 属性必须显式设置，Gin 默认不设
Gin 的 c.SetCookie 方法不会自动设置 SameSite，它默认为 http.SameSiteDefaultMode（Go 1.19+），但该模式在多数浏览器中等效于未声明，无法防 CSRF。必须手动传入明确值，否则形同虚设。
常见错误是忽略这个字段，或误用字符串（如 "Lax"）——SameSite 是整型常量，不是字符串：
-
http.SameSiteStrictMode：最严，跨站 POST/GET 都拦截，可能影响 OAuth 流程 -
http.SameSiteLaxMode：推荐默认值，允许安全的 GET 表单提交（如点击链接），拦截 POST 和 JS 发起的请求 -
http.SameSiteNoneMode：必须搭配Secure: true，否则现代浏览器直接拒收
示例（正确写法）：
c.SetCookie("session_id", token, 3600, "/", "", true, true)
❌ 错误写法（无 SameSite）：
立即学习“go语言免费学习笔记（深入）”；
c.SetCookie("session_id", token, 3600, "/", "", true, true)
✅ 正确写法（显式指定 Lax）：
cookie := &http.Cookie{
Name: "session_id",
Value: token,
Path: "/",
HttpOnly: true,
Secure: true,
SameSite: http.SameSiteLaxMode,
MaxAge: 3600,
}
http.SetCookie(c.Writer, cookie)
Domain 字段填错会导致 SameSite 失效
SameSite 行为与 Domain 强相关。若设置了 Domain，浏览器会按「注册域名」规则匹配（如 example.com 匹配 api.example.com），但填错会直接让 Cookie 不发送，SameSite 也就无从谈起。
本地开发最常踩坑：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
Domain: "localhost"—— 无效，浏览器不认，必须留空 -
Domain: ".localhost"—— 语法错误，.前缀只对真实域名有效（如.example.com） -
Domain: "127.0.0.1"—— 同样不支持，和localhost一样被视作「非注册域名」
结论：开发环境一律设 Domain: ""；生产环境若需跨子域共享（如 app.example.com ↔ api.example.com），才填 "example.com"（不带点前缀）。
Secure + SameSite=None 必须同时启用，否则被浏览器丢弃
Chrome 80+、Firefox 79+ 等主流浏览器强制要求：SameSite=None 的 Cookie 必须同时设置 Secure: true，否则直接拒绝存储。
这意味着：
- 本地 HTTP 开发时不能用
SameSiteNoneMode，否则 Cookie 根本不存 - 测试环境若没配 HTTPS，要么换
Lax，要么临时关掉 SameSite（不推荐） - 即使后端用了反向代理（如 Nginx 终止 HTTPS），也要确保
c.Request.TLS != nil或通过X-Forwarded-Proto正确判断，否则Secure: true会误设导致失败
检查是否真走 HTTPS 的惯用方式：
secure := c.Request.TLS != nil || c.GetHeader("X-Forwarded-Proto") == "https"
c.SetCookie("token", val, 3600, "/", "", secure, true)
SameSite 不是 CSRF 全能解，后端仍需校验 Origin/Referer
SameSite=Lax 对大部分 CSRF 有效，但存在绕过场景：攻击者构造一个 GET 表单（<form method="GET">）并诱导用户点击，浏览器会带上 Cookie 发送请求。如果后端接口接受 GET 且修改状态（如删除资源），就可能被利用。
所以不能只依赖 SameSite：
- 所有状态变更接口（POST/PUT/DELETE）必须校验
Origin或Referer头 - 敏感操作（如转账、改密码）建议额外加 CSRF Token（服务端签发、客户端回传）
- 避免在 GET 接口中做写操作，这是 REST 原则，也是防御基础
SameSite 是纵深防御的一环，不是终点。它防不住恶意页面发起的合法 GET 请求，也防不住已登录用户被诱导点击的钓鱼链接。
