html本身不提供csrf防护能力，所有防护必须由服务端动态生成并绑定session的token、前端从dom安全提取并手动携带至ajax请求头或表单字段、服务端严格校验三者协同完成；静态值、url或localstorage传输、模板缓存、一次性token等均导致防护失效。
HTML本身不提供CSRF防护能力，所有防护必须由服务端生成、前端正确携带、服务端严格校验三者协同完成；单靠在HTML里加个<input type="hidden">或写死一个值，等于没防。
服务端必须动态生成并绑定 session 的 Token
Token 不能是静态字符串，也不能从 URL、localStorage 或 sessionStorage 读取——这些地方在 XSS 下可被窃取。服务端每次渲染含表单的页面时，必须调用框架提供的安全函数（如 Django 的 csrf_token、Flask-WTF 的 generate_csrf()、ASP.NET 的 @Html.AntiForgeryToken()）实时生成，并存入当前用户 session（或加密后写入 SameSite=Lax 的 Cookie）。
- 常见错误：模板缓存了 HTML，导致多个用户看到同一个 Token；应禁用模板层对含 Token 页面的缓存
- Django 若设
CSRF_USE_SESSIONS = False，Token 存 Cookie，此时响应头必须含Set-Cookie: csrftoken=...; SameSite=Lax - Express 使用
csrf-protection时，中间件必须在body-parser之后、路由之前挂载，否则req.body为空，校验直接失败
前端必须从 DOM 安全提取并手动携带 Token
浏览器不会自动把 Token 塞进 AJAX 请求体或 header，前端 JS 必须主动读取、再显式传出去。推荐统一用 <meta name="csrf-token" content="..."> 埋点，避免和表单字段名耦合。
- 提取方式：
document.querySelector('meta[name="csrf-token"]')?.getAttribute('content')，别用document.getElementsByName('csrf_token')[0].value—— 多个表单时容易取错 - fetch 发送非 GET 请求时，必须加 header：
headers: { 'X-CSRF-Token': token } - 服务端若不支持从 header 校验（如 Django 默认只查 form-data），会返回 403；Django 需额外设
CSRF_HEADER_NAME = 'HTTP_X_CSRF_TOKEN' - 禁止把 Token 写死在 JS 字符串里，或从
location.search解析——URL 参数会被日志、代理、Referer 泄露
多标签页、刷新、后退场景下 Token 失效怎么破
403 报错八成不是前端漏传，而是服务端用了“一次性 Token”或页面被浏览器缓存。Token 生命周期必须匹配真实会话，而非单次请求。
- 禁用“用一次就作废”模式（常见于部分 PHP 手写实现），改用“每会话单 Token”，只要 session 有效，Token 就持续可用
- 服务端响应需带
Cache-Control: no-store, no-cache，防止浏览器缓存含旧 Token 的 HTML - AJAX 提交失败后，不要重试旧 Token；应触发一次轻量级接口（如
/csrf-refresh）获取新 Token，再重发原请求 - 若用户登出或 session 过期，前端应清空 meta 中的 Token 值，避免后续请求带着无效值反复 403
最易被忽略的一点：CSRF 防护成败不取决于 Token 有多长或多随机，而在于服务端生成、传输路径、校验时机这三点是否严丝合缝。哪怕 Token 是 128 位 UUID，只要它被缓存、被复用、或校验逻辑漏掉 AJAX 路径，整个防护就形同虚设。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
