fiber csrf防护必须手动集成csrf.new()、严格按序注册、配置存储并配合前端，缺一不可；中间件须置于所有敏感路由前，否则校验失效。
必须手动集成 csrf.New()，且顺序、存储、前端配合三者缺一不可，否则等于没防。
中间件必须在路由前注册，且不能漏挂敏感路径
Fiber 不会自动注入任何安全中间件。你写了 app.Use(csrf.New())，但如果它出现在 app.Post("/api/transfer", handler) 之后，那这个 POST 路由完全不会经过 CSRF 校验。
- 正确顺序：先
app.Use(csrf.New())，再定义所有需防护的路由（如/user/settings、/api/submit） - 静态资源（
/public/*）、健康检查（/health）可放中间件之前，避免无谓校验和 token 泄露风险 - 若用分组路由（
api := app.Group("/api")），中间件也得在分组定义前注册，否则子路由不生效
双提交 Cookie 模式下，token 必须从 Cookie 读出并手动塞进请求头或表单
默认模式不依赖 session，token 由中间件生成并设为 csrf_token Cookie，但浏览器不会自动把它填进 X-CSRF-Token 请求头——这是两个独立位置，必须前端桥接。
- HTML 表单需显式插入：
<input type="hidden" name="csrf_token" value="{{.CSRFToken}}"> - fetch 请求要手动提取：
document.cookie.match(/csrf_token=([^;]+)/)?.[1]，再设headers: { 'X-CSRF-Token': token } - 若用
credentials: 'include'，Cookie 会发，但头仍为空；不设头或字段名错（比如写成csrf-token），校验直接失败
要用同步令牌模式，必须提前配好 session 存储
仅调用 session.New() 不够，内存存储（无参数）只适合开发；生产必须配持久化后端（Redis / Badger），否则 csrf.New() 启动时会 panic。
- 顺序关键：先
app.Use(session.New(...))，再app.Use(csrf.New())，否则中间件拿不到 session 实例 - 此时 token 绑定 session ID，即使 Cookie 被窃也无法重放；但代价是每次校验都要查存储，有性能开销
- Cookie 属性必须设
SameSite=Lax或Strict，否则跨站请求仍可能携带凭证
容易被忽略的硬性约束
CSRF 防护不是“加个中间件就完事”，几个隐性条件不满足，整个链路就断了：
-
csrf_tokenCookie 必须设HttpOnly=false（JS 才能读），但同时必须配SameSite=Lax，二者缺一不可 - 不能把 token 放 URL 查询参数里——会被日志、Referer、代理缓存泄露
- iframe 场景下，中间件本身不拦截 iframe 加载，得额外配
TrustedOrigins和严格SameSite会话 Cookie - GET 请求默认不校验，但绝不该用 GET 执行敏感操作（如
/user/delete?id=123），这是设计层面漏洞
