csrf中间件必须在路由前注册，否则静态文件等未匹配路径会绕过校验；token需从响应头或模板正确注入；状态变更get必须显式保护；多实例需统一密钥和samesite策略。
CSRF中间件必须在路由前注册，否则无效
Go的HTTP中间件执行顺序决定它是否能拦截到所有受保护请求。如果把CSRF中间件放在http.ServeMux或gorilla/mux路由之后注册，静态文件、健康检查等未匹配路由的路径就绕过了校验——攻击者可能伪造/favicon.ico或/healthz发起带Cookie的POST，照样触发漏洞。
实操建议：
- 用
gorilla/csrf时，确保csrf.Protect()是第一个中间件，包裹整个路由器：handler := csrf.Protect([]byte("32-byte-key"))(r) - 若用
net/http原生ServeMux，必须手动包装：http.Handle("/", csrf.Protect([]byte("key"))(myHandler)) - 不要在某个子路由上单独加CSRF，比如
r.HandleFunc("/api", csrf.Protect(...)(apiHandler))——这会让/login等表单入口漏掉防护
token必须从响应头或HTML模板中正确注入
gorilla/csrf默认只通过X-CSRF-Token响应头下发token，但前端AJAX请求不会自动读取它；而表单提交又依赖_csrf隐藏字段。两者不一致就会出现“token存在但校验失败”。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 前端用
fetch发POST，没手动读X-CSRF-Token头，也没传headers: { 'X-CSRF-Token': token } - HTML模板里忘了写
{{.CSRFToken}}（Gin）或{{template "csrf_field" .}}（gorilla/securecookie配套模板） - 用
csrf.SameSiteLaxMode时，跨站GET跳转后首次POST会因Cookie未携带导致token不匹配
参数差异：启用csrf.Secure(true)要求HTTPS，否则浏览器拒绝发送Cookie；csrf.HttpOnly(false)才允许JS读取token——但别设true，否则前端拿不到。
GET请求默认豁免，但含状态变更的GET必须显式保护
CSRF中间件默认跳过GET、HEAD、OPTIONS，这是合理设计。但如果你的API用GET /api/v1/user/delete?id=123删数据，就等于把CSRF漏洞直接敞开。
实操建议：
- 立刻改用
DELETE或POST+ body传ID，这是REST规范，也是安全底线 - 如果真要保留状态变更GET（如遗留系统），必须手动强制校验：
csrf.Protect(key, csrf.Secure(false), csrf.TrustedOrigins([]string{"example.com"}))(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { if r.Method == "GET" && strings.Contains(r.URL.Path, "/unsafe-delete") { // 手动验证token if !csrf.ValidToken(r) { http.Error(w, "invalid", http.StatusForbidden); return } } })) - 注意
csrf.ValidToken(r)只校验token格式和签名，不检查是否过期——过期时间由csrf.MaxAge控制，默认3600秒
多实例部署时，密钥和SameSite策略必须严格统一
多个Web节点共用一套CSRF保护，但各自生成token时用不同密钥，会导致A节点签发的token在B节点校验失败；而SameSite=Strict在重定向场景下会丢失Cookie，造成合法用户反复403。
容易踩的坑：
- 用
os.Getenv("CSRF_KEY")读密钥，但环境变量在不同机器上不一致——必须确保所有实例加载同一份32字节密钥（推荐从配置中心或Secret Manager拉取） - 本地开发用
csrf.SameSite(csrf.SameSiteLaxMode)，生产却误配成SameSiteStrictMode，结果用户从邮件链接点击进入后无法提交表单 - 反向代理（如Nginx）没透传
Origin头，导致TrustedOrigins校验失败，需加proxy_set_header Origin $scheme://$host;
性能影响很小，gorilla/csrf的token生成和校验都是内存操作，但密钥轮换需滚动重启，否则新旧密钥并存期间会出现短暂校验失败。
最麻烦的是前端和后端对token生命周期的理解偏差：后端默认1小时过期，但前端可能缓存了页面里的旧token长达数小时——别指望用户刷新页面，得靠接口返回403时前端主动重取token并重试请求。
