Go HTTP客户端需启用cookiejar.New并配置PublicSuffixList防跨域泄漏；服务端设Cookie须用Secure/HttpOnly/SameSite常量，禁用字符串硬编码；CSRF防护须分离Token生成、传输与校验，禁用Referer/Origin主校验。
Go HTTP客户端如何安全传递Cookie
Go标准库的http.Client默认不会自动管理Cookie，除非你显式启用http.CookieJar。不加控制地复用Cookie或手动拼接Cookie头，极易导致会话泄露或跨域泄漏。
常见错误现象：登录后请求返回401、同一客户端在不同域名间意外共享Session ID、测试环境Cookie被带到生产环境。
- 始终用
cookiejar.New创建独立Jar，传给http.Client，别用nil或全局共享Jar - 设置
Jar时传入&http.JarOptions{PublicSuffixList: publicsuffix.List}（需引入golang.org/x/net/publicsuffix），否则.example.com可能错误接受attacker.example.com发来的Cookie - 敏感请求（如支付、密码修改）前，手动调用
jar.SetCookies(u, []*http.Cookie{...})只注入必要Cookie，避免自动携带无关域的Cookie
HTTP服务端如何正确设置Secure/HttpOnly/SameSite Cookie
http.SetCookie本身不校验参数合法性，SameSite值写错（比如写成"Lax"而非http.SameSiteLaxMode）会导致浏览器直接忽略该Cookie，且无任何提示。
使用场景：用户登录成功后下发Session Cookie；API返回临时Token供前端后续请求携带。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
Secure必须为true且服务跑在HTTPS下，本地开发用localhost时可临时设false，但上线前必须删掉条件判断逻辑 -
HttpOnly对Session ID类Cookie必须为true，防止XSS窃取；但JWT等需JS读取的Token不能设此字段 -
SameSite优先用http.SameSiteStrictMode或http.SameSiteLaxMode，避免字符串硬编码；Lax兼容大部分GET跳转，Strict防CSRF更强但可能破坏正常流程
Go中验证CSRF Token的典型实现方式
CSRF防护不是“加个中间件就完事”，关键在Token生成、传输、校验三环节的隔离性。用gorilla/csrf库时，若把Token存在URL查询参数里，会被Referer泄露；若存进Cookie又没配SameSite，等于白做。
性能影响：每次请求都生成新Token会拖慢响应，但复用旧Token又降低安全性。折中方案是“Token绑定Session + 有限生命周期”。
- 生成Token时用
csrf.Token(r)，它依赖底层Session或http.Request.Context中的密钥，确保每个用户唯一 - 传输方式选Header（如
X-CSRF-Token）优于Cookie，避免浏览器自动携带；若必须放Cookie，务必设SameSite=Strict且Path精确到接口路径 - 校验失败时返回
http.StatusForbidden而非http.StatusBadRequest，防止攻击者通过状态码差异探测Token有效性
为什么net/http自带的Cookie机制不防CSRF
http.SetCookie和http.Request.Cookies()只是HTTP头的解析工具，不包含任何策略逻辑。浏览器照单全收Set-Cookie响应头，只要域名、路径、时间匹配，下次同源请求就会自动带上——这正是CSRF能成功的基础。
容易踩的坑：以为设置了SameSite=Lax就高枕无忧，但Lax模式下GET表单提交仍被允许；或者把CSRF Token和Session ID存在同一个Cookie里，导致Token被XSS读取后直接伪造请求。
- CSRF防护必须由业务层主动介入：生成Token、要求客户端提交、比对一致性
- 不要试图用
Origin或Referer头做主要校验——它们可被绕过，只能作为辅助手段 - 静态资源（如
/static/js/app.js）响应里绝不嵌入动态Token，否则CDN缓存会污染所有用户
