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”，没有具体原因
POST/PUT/DELETE 卡在 OPTIONS 预检
Axios、Fetch 默认发 Content-Type: application/json，这属于“非简单请求”，浏览器一定会先发 OPTIONS。如果后端没响应这个预检，真实请求根本不会发出。
确保：
立即学习“Python免费学习笔记（深入）”；
- 没手动写
@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后面
FastAPI 的 CORSMiddleware 配置陷阱
FastAPI 的 CORSMiddleware 默认不支持 allow_credentials=True 与 allow_origins=["*"] 共存 —— 这是硬性限制，会直接抛 ValueError。
正确做法是明确列出可信源：
- 开发环境：
allow_origins=["http://localhost:3000", "http://127.0.0.1:3000"]</li> <li>生产环境：<code>allow_origins=["https://myapp.com", "https://admin.myapp.com"]
（不能带端口，必须 HTTPS） - Electron/WebView 本地调试：
allow_origins=["file://", "http://localhost:3000"]
另外，max_age 设得过大（如 86400）可能导致预检缓存过久，改了配置却迟迟不生效；建议开发期设为 600 或更低。
