gorilla/csrf.token(r)返回空字符串，主因是session未初始化或密钥为空；必须用securecookie.new初始化store且hashkey、blockkey非nil，并确保store.get和session.save已执行。
gorilla/csrf.Token(r) 返回空字符串？先查 session 和密钥初始化
这几乎是最常卡住人的起点：你调用了 csrf.Token(r)，但返回空字符串，表单里啥也没塞进去。它不报错，只沉默返回 ""——问题不在 Token 逻辑本身，而在底层依赖没就位。
必须确保两件事同时成立：
-
gorilla/sessions的 store 已用securecookie.New(hashKey, blockKey)正确初始化，hashKey和blockKey都不能为nil或空字符串（开发环境也别偷懒） - 中间件链中，
store.Get(r, "session-name")必须在调用csrf.Token(r)前执行过，且后续调用了session.Save(r, w)；否则csrf拿不到有效 session 实例
验证方式很简单：在 handler 里加一行 log.Printf("session ID: %v", session.ID())。如果打印出空或 panic，说明 session 根本没活起来。
POST 请求 403？检查 Token 传输通道是否匹配
页面能打开、表单能渲染，但一点提交就 403 ——这不是 Token 没生成，是前后端“对不上号”。gorilla/csrf 默认只从两个位置读 Token：
-
_csrf表单字段（传统<form></form>提交） -
X-CSRF-Token请求头（AJAX/fetch 场景）
常见翻车点：
- 前端用
fetch却没设credentials: 'include'→ Cookie 不带，Session 找不到，Token 校验直接跳过 - 把 Token 塞进
localStorage→ XSS 一拿一个准；应优先用document.cookie或模板注入（如{{.CSRFToken}}） - Header 名写成
X-CSRF-TOKEN或x-csrf-token→ 大小写敏感，gorilla/csrf只认X-CSRF-Token
为什么 SameSite=Lax 不能跳过 Token 校验？
SameSite 是浏览器策略，CSRF Token 是应用层强制关卡——前者拦不住所有攻击面，后者才是兜底。
比如这个真实绕过场景：<form method="POST" action="https://yoursite.com/transfer"><input name="amount" value="10000"></form>
<script>document.forms[0].submit()</script>。Lax 允许 POST 表单从外站自动提交，只要不是 GET 跳转，它就不拦。
更危险的是 iframe + 自动 submit：钓鱼页嵌入你的支付页 iframe，脚本触发表单提交，SameSite=Lax 完全失效。而 Token 绑定到 session，每次校验都走服务端逻辑，不依赖 Referer、不被浏览器策略演进拖累。
手动实现 Token 校验时，恒定时间比对和一次性清除不能省
如果你不用 gorilla/csrf，而是自己基于 net/http + gorilla/sessions 手写，有两点极易忽略但极其关键：
- 比对 Token 时，必须用恒定时间比较（如
crypto/subtle.ConstantTimeCompare），否则可能被时序攻击推断出 Token 字节 - 校验通过后，必须立即从 session 中删除该 Token（
delete(session.Values, "csrf_token")）或标记为已使用；否则重放攻击可反复利用同一 Token
另外，crypto/rand.Read 生成的 32 字节随机数是底线，别用 math/rand；Base64 编码必须用 base64.URLEncoding，避免 URL 解析失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
