cors(app)在生产环境易出错，因默认仅设access-control-allow-origin，缺失access-control-allow-methods、allow-headers等关键头，导致axios等发起的非简单请求预检失败；需显式配置origins白名单、methods、allow_headers及supports_credentials，并确保nginx等代理透传cors响应头。
flask-cors 能解决绝大多数 Flask 跨域问题，但直接写 CORS(app) 很可能在生产环境出错——尤其是当你用 Axios 发送带 Content-Type: application/json 的 POST 请求，或前端启用了凭据（如 cookies）时。
为什么 CORS(app) 在开发期能过，上线就报错？
浏览器对“非简单请求”会先发一个 OPTIONS 预检请求，而预检是否通过，取决于后端是否返回了完整且匹配的 CORS 响应头。CORS(app) 默认只设 Access-Control-Allow-Origin，缺了 Access-Control-Allow-Methods、Access-Control-Allow-Headers 等关键头，尤其当 Axios 自动带上 Content-Type 或自定义 header 时，预检直接失败。
常见错误现象：
- 控制台报
No 'Access-Control-Allow-Origin' header is present（其实头存在，但预检没过） - Network 面板里
OPTIONS请求状态是 405 或 500 - POST 请求根本没发出，卡在预检阶段
正确做法是显式声明支持项：
• 指定 origins 白名单，禁用 "*"（尤其含 supports_credentials=True 时，"*" 会被浏览器拒绝）
• 显式列出允许的 methods，比如 ["GET", "POST", "PUT", "DELETE"]
• 明确声明 allow_headers，至少包含 ["Content-Type", "Authorization"]
• 若前端需要传 cookie，必须同时设 supports_credentials=True 且 origins 不能为 "*"
from flask import Flask from flask_cors import CORS <p>app = Flask(<strong>name</strong>)</p><p>CORS(app, origins=["<a href="https://www.php.cn/link/8e5687e2d6ab87e5da2f833f3e8986a4">https://www.php.cn/link/8e5687e2d6ab87e5da2f833f3e8986a4</a>", "<a href="https://www.php.cn/link/bf3e87e214621d9025abdcd1aa8ab2a2">https://www.php.cn/link/bf3e87e214621d9025abdcd1aa8ab2a2</a>"], methods=["GET", "POST", "PUT", "DELETE", "OPTIONS"], allow_headers=["Content-Type", "Authorization", "X-Requested-With"], supports_credentials=True )</p>
POST 请求仍被拦截？检查 Axios 是否触发了预检
Axios 默认对 application/json 请求加 Content-Type: application/json 头，这属于“非简单请求”，必走预检。
但如果你用 FormData 提交（比如上传文件），Axios 不会自动加 Content-Type，而是让浏览器设为 multipart/form-data; boundary=... —— 这个也会触发预检，因为它是非简单内容类型。
所以别依赖“没手动设 header 就没事”。真实判断依据是：
-
GET+ 纯 query 参数 + 简单 header（Accept、Content-Type为text/plain等）→ 不预检 - 其他情况（尤其
POST+ JSON / FormData / 自定义 header）→ 必预检
确保后端对 OPTIONS 路由有响应，且返回头与主路由一致。flask-cors 默认会自动处理 OPTIONS，但前提是它“知道你要暴露哪些方法和头”——也就是上面显式配置的必要性。
部署到 Nginx 或 Docker 后 CORS 又失效？注意代理层覆盖响应头
很多线上问题根本不在 Flask，而在反向代理。
Nginx 默认不透传后端的 Access-Control-* 响应头，尤其当你用了 add_header 但没加 always 参数时，OPTIONS 响应可能不带 CORS 头。
典型错误配置：
location /api/ {
proxy_pass http://flask_app;
add_header 'Access-Control-Allow-Origin' 'https://www.php.cn/link/bf3e87e214621d9025abdcd1aa8ab2a2';
}
这个 add_header 不作用于 OPTIONS 响应（因为 Nginx 默认只给 2xx/3xx 加），结果预检失败。
正确写法（Nginx）：
location /api/ {
proxy_pass http://flask_app;
add_header 'Access-Control-Allow-Origin' 'https://www.php.cn/link/bf3e87e214621d9025abdcd1aa8ab2a2' always;
add_header 'Access-Control-Allow-Methods' 'GET,POST,PUT,DELETE,OPTIONS' always;
add_header 'Access-Control-Allow-Headers' 'Content-Type,Authorization,X-Requested-With' always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
}
Docker 环境同理：确认容器外的网关（如 Traefik、ALB）没有 strip 掉 CORS 头。
关键点容易被忽略：预检请求不是 Flask 应用代码处理的“业务逻辑”，而是 flask-cors 中间件在 WSGI 层拦截并响应的。一旦代理层、CDN 或负载均衡器介入，它就可能被截断或重写。调试时务必看 Network 面板里 OPTIONS 请求的 Response Headers，而不是只盯着你的 @app.route 返回内容。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
