Token和Header验证是防止csrf的有效手段，golang中通过生成一次性Token、前端携带（表单隐藏域或X-CSRF-Token头）、服务端校验session中Token一致性来实现，需绑定用户session、避免URL传递、统一分布式session存储。
使用 Token 和 Header 验证是防止 CSRF（跨站请求伪造）的有效手段，golang 中可通过标准库 net/http 结合中间件实现。核心思路是：服务端生成一次性或短期有效的 Token，前端在表单或请求头中携带，后端校验其合法性与一致性。
生成并下发 CSRF Token
每次用户访问需要防护的页面（如登录页、表单页），服务端生成随机 Token 并存入用户 session 或加密签名后返回给前端。推荐使用 gorilla/sessions 管理 session，或用 crypto/rand 生成安全随机字符串：
- 用
crypto/rand.Read生成 32 字节随机字节，再 base64 编码为字符串 - 将 Token 存入 session（如
session.Values["csrf_token"] = token），同时设置过期时间（如 30 分钟） - 通过模板变量或 API 接口把 Token 传给前端，例如：
<input type="hidden" name="csrf_token" value="{{.CSRFToken}}">
前端请求携带 Token
前端需在两种场景中带上 Token：
- 表单提交时：作为隐藏字段（
<input type="hidden" name="csrf_token">），后端从r.FormValue("csrf_token")获取 - ajax 请求时：统一在请求头中添加，如
X-CSRF-Token: xxx，后端从r.Header.Get("X-CSRF-Token")读取 - 建议对非 GET/HEAD 请求（POST/PUT/delete）强制校验，GET 请求一般无需防护
服务端校验 Token
在处理敏感请求前，插入中间件做校验：
立即学习“go语言免费学习笔记（深入）”；
- 从 session 中取出原始 Token（注意防空 session）
- 对比请求中传入的 Token 是否一致（严格字符串相等，不忽略空格）
- 可选增强：验证 Token 签名（如用 Hmac 加密时间戳+随机数），防止客户端篡改
- 校验失败返回
http.StatusForbidden，不执行后续业务逻辑
注意事项与常见坑
实际部署中容易忽略以下细节：
- Token 必须绑定用户 session，不能全局共享；不同用户的 Token 不可复用
- 避免在 URL 参数中传递 Token，防止泄露到日志或 Referer
- 若使用多实例部署，session 存储需统一（如 redis），否则 Token 校验可能失败
- 前端发请求前应确保已获取最新 Token，避免因页面长时间未刷新导致 Token 过期
基本上就这些。不复杂但容易忽略细节，关键是前后端约定清晰、Token 生命周期可控、校验逻辑不可绕过。