95%的CSRF verification failed错误源于模板漏写{% csrf_token %}、CsrfViewMiddleware被注释或位置错误（须在SessionMiddleware之后、AuthenticationMiddleware之前）、AJAX请求未携带X-CSRFToken头，修复这三处即可解决。
95% 的 CSRF verification failed. Request aborted 错误，不是被攻击了，而是模板漏写 {% csrf_token %}、CsrfViewMiddleware 被注释或顺序错、AJAX 请求没传 X-CSRFToken 头——修这三处，基本就稳了。
POST 表单里为什么必须加 {% csrf_token %}
Django 要求所有发往本域的 POST（以及 PUT、DELETE）请求携带有效令牌，而模板漏掉这个标签，后端就收不到校验依据。
- 必须在
<form method="post"></form>内部、任意<input>之前插入{% csrf_token %} - 不能写成
{% csrf_token %}放在<form></form>外面，也不能只靠 JS 动态插入 DOM —— 模板渲染时就得存在 - 用
render()（而非HttpResponse直接返回字符串），RequestContext才会自动注入csrf_token变量 - 错误示例：
<form method="post"><input name="email"></form>→ 缺 token，必 403 - 正确示例：
<form method="post">{% csrf_token %}<input name="email"> </form>
CsrfViewMiddleware 在 MIDDLEWARE 里怎么排才对
django.middleware.csrf.CsrfViewMiddleware 是整个机制的执行者。它不在中间件链里，或位置不对，token 就无法绑定 session，校验直接失败。
- 必须放在
SessionMiddleware之后、AuthenticationMiddleware之前 - 错误顺序：
SessionMiddleware→AuthenticationMiddleware→CsrfViewMiddleware→ 会导致 token 无法关联用户 session - 如果用了
corsheaders，CorsMiddleware必须放在CsrfViewMiddleware之前，否则跨域预检可能干扰 token 读取 - 禁用它（比如注释掉）虽能绕过报错，但等于裸奔 —— 仅限本地调试，绝不可上生产
fetch / axios 发 POST 时怎么带 X-CSRFToken 头
前端不会自动附带 cookie 里的 csrftoken，必须手动提取并塞进请求头。默认 cookie 名是 csrftoken，可通过 CSRF_COOKIE_NAME 配置修改，取值前先确认。
立即学习“Python免费学习笔记（深入）”；
- 标准做法：读 cookie 后设 header：
headers: {'X-CSRFToken': csrftoken}，Django 通过CSRF_HEADER_NAME（默认HTTP_X_CSRFToken）读取 - 别把 token 放 URL 参数（如
?token=xxx）或 request body（如data: {csrfmiddlewaretoken: 'xxx'}）里 —— 既不安全也不被 Django 默认识别 - 不要用
document.cookie直接解析，推荐用现成工具函数（如 Django 官方文档提供的getCookie()） - 若启用了
CSRF_USE_SESSIONS=True或CSRF_COOKIE_HTTPONLY=True，就不能从 cookie 读，得从响应 HTML 的 hidden input 或 API 返回字段里取 —— 这种情况容易被忽略
最易被忽略的是：CSRF 防护必须和会话生命周期强绑定。每次新页面加载都要刷新 session['csrf_token']，否则重放攻击可绕过；Set-Cookie 响应头没加 Secure=True; SameSite=Lax（上线环境 Secure 必须开），令牌就可能被中间人截获。
