CSRFProtect 必须配置 SECRET_KEY，否则静默失效；模板中表单用 {{ form.csrf_token }}，纯 HTML 或 AJAX 用 {{ csrf_token() }}；AJAX 需手动带 X-CSRFToken 请求头；禁用 CSRF 需谨慎评估风险。
CSRFProtect 初始化必须配 SECRET_KEY
没设 SECRET_KEY，CSRFProtect 就会静默失效——表单提交不报错，但 form.validate_on_submit() 永远返回 False，错误信息是 {'csrf_token': ['The CSRF token is missing.']}。
-
SECRET_KEY是生成和校验 CSRF 令牌的根基，不能留空、不能用默认值（如'dev'） - 推荐从环境变量读取：
app.config['SECRET_KEY'] = os.environ.get('SECRET_KEY') - 如果只用于 CSRF（不用 Flask-Login 等），也可单独设
WTF_CSRF_SECRET_KEY，避免复用主密钥
模板里怎么插 token：form.csrf_token vs csrf_token()
两种写法本质不同，别混用：
- 用
FlaskForm子类（比如LoginForm）时，必须写{{ form.csrf_token }}——它自动渲染带 name="csrf_token" 的隐藏 input，且和表单绑定校验逻辑 - 纯 HTML 表单或 AJAX 场景，用
{{ csrf_token() }}获取原始 token 字符串，再手动塞进请求头或字段（比如<input type="hidden" name="csrf_token" value="{{ csrf_token() }}">） - 直接写
<input name="csrf_token" value="{{ csrf_token() }}">而不加type="hidden"可能被浏览器自动填充，导致 token 泄露
AJAX 请求带 CSRF token 的三个实操要点
前后端分离项目里，token 必须从服务端吐给前端，再由 JS 主动带上。常见坑不是“怎么传”，而是“怎么保活”：
- 把 token 放在响应 HTML 的
<meta name="csrf-token" content="{{ csrf_token() }}">里，JS 用document.querySelector('meta[name="csrf-token"]').content拿，最稳 - fetch 或 axios 发送 POST/PUT/DELETE 时，**必须**加请求头：
headers: { 'X-CSRFToken': token }（注意大小写，Flask-WTF 默认认这个头） - 别依赖 cookie 自动携带——CSRF token 默认不设
HttpOnly，但也不会自动附在 AJAX 请求里；靠 cookie 传需额外配置WTF_CSRF_CHECK_DEFAULT和钩子函数，反而更易出错
禁用 CSRF 的真实场景和风险边界
全局关掉 WTF_CSRF_ENABLED = False 是懒办法，99% 的情况不该这么做。真要绕过，得清楚代价：
- 单个视图禁用：用
@app.route(..., methods=['POST'])+ 手动取request.form，但你得自己防重放、防篡改、做登录态校验 - 单个表单禁用：
MyForm(csrf_enabled=False)，仅适用于内部工具、调试接口等明确无用户会话的场景 - Dropzone、CKEditor 这类富上传组件，要开
DROPZONE_ENABLE_CSRF = True并确保其 JS 正确读取并发送 token，否则 400 错误里看不到具体原因
CSRF 不是“加了就安全”，而是“不加大概率不安全”。最常被忽略的是时间戳校验：WTF_CSRF_TIME_LIMIT 默认 3600 秒，如果用户页面挂机两小时再提交，token 就已过期——这时候该返回友好提示，而不是让表单静默失败。
