Flask-CORS未生效主因是未实际接管路由，常见于CORS(app)写在@app.route之后、蓝图未单独启用、多进程热重载未加载新配置、Nginx吞掉响应头、自定义中间件覆盖头，或origins白名单配错导致预检失败。
Flask-CORS 为什么没生效
不是插件坏了，而是它根本没管到你的路由。最常见的是 CORS(app) 写在了所有 @app.route 之后，或者用了蓝图（Blueprint）但没单独启用 CORS —— CORS(app) 不会自动透传到未注册的蓝图里。
其他典型场景包括：
- 开发时热重载启了两个 Flask 进程，改的配置只加载到了旧进程
- Nginx 或 uWSGI 吞掉了响应头，
Access-Control-Allow-Origin根本没发出去 - 自定义了
before_request或 WSGI wrapper，覆盖或清空了 CORS 插件写的响应头
origins 白名单配错导致 403 或静默失败
"*" 看起来省事，但它和 supports_credentials=True（比如前端带 cookie 或 Authorization 头）直接冲突，浏览器会直接拒绝响应，连错误都不报全 —— 控制台可能只显示 “CORS error”，没有具体原因。
正确做法是明确列出可信源：
立即学习“Python免费学习笔记（深入）”；
- 开发环境：
origins=["http://localhost:3000", "http://127.0.0.1:3000"] - 生产环境：
origins=["https://myapp.com", "https://admin.myapp.com"]（不能带端口，必须 HTTPS） - Electron/WebView 本地调试：
origins=["file://", "http://localhost:3000"]
正则匹配（如 r"https?://(localhost|myapp)\.com(:\d+)?"）容易漏转义或匹配过宽，调试困难，不建议在关键路径上用。
POST/PUT/DELETE 请求卡在 OPTIONS 预检
Axios、Fetch 默认发 Content-Type: application/json，这属于“非简单请求”，浏览器一定会先发 OPTIONS。如果后端没响应这个预检，真实请求根本不会发出。
确保：
- 没手动写
@app.route("/xxx", methods=["OPTIONS"])—— 这会覆盖flask-cors的默认处理逻辑 -
CORS(app, methods=["GET", "POST", "PUT", "DELETE", "OPTIONS"])显式包含OPTIONS - 如果用了蓝图，优先用装饰器：
@cross_origin(origins=["http://localhost:3000"])放在具体视图函数上，比全局配置更可控
Django 中 corsheaders 中间件顺序错乱
CorsMiddleware 必须放在 SecurityMiddleware 之前，否则安全中间件可能提前中断响应，导致 CORS 头被截断。这不是可选建议，是执行顺序依赖。
检查 MIDDLEWARE 列表：
- ✅ 正确：
'corsheaders.middleware.CorsMiddleware'在第一或第二位 - ❌ 错误：放在
SessionMiddleware或CsrfViewMiddleware后面 - 别忘了在
INSTALLED_APPS里注册'corsheaders'，否则中间件根本不会加载
生产环境务必禁用 CORS_ALLOW_ALL_ORIGINS = True，改用 CORS_ALLOWED_ORIGINS 显式声明域名 —— 否则带凭证的请求会直接失败，且存在安全风险。
