应使用flask-cors扩展而非手写响应头，因其自动处理OPTIONS预检、避免漏配Access-Control-Allow-Credentials等关键头，支持路由级细粒度控制，兼顾安全性与可靠性。
直接用 flask-cors 扩展，别手写响应头——手写容易漏 Access-Control-Allow-Credentials 或搞错预检（OPTIONS）逻辑，反而更难调试。
为什么本地前端调 Flask 接口总卡在 OPTIONS 请求失败
浏览器在发送带认证、自定义 header 或非简单方法（如 PUT、DELETE）的请求前，会先发一个 OPTIONS 预检请求。Flask 默认不处理这个请求，返回 405 或空响应，导致跨域失败。
- 典型错误现象：
Failed to load http://localhost:5000/api/data: Response to preflight request doesn't pass access control check - 常见诱因：前端用了
fetch并设置了credentials: 'include'，或传了Content-Type: application/json以外的类型（如text/plain） - 手写
@app.after_request加 header 往往只覆盖了主请求，没响应OPTIONS，或漏了Access-Control-Allow-Headers字段
用 flask-cors 控制粒度比全局放行更安全
flask-cors 不仅自动处理 OPTIONS，还支持按路由、蓝图甚至视图函数级别配置，避免“全开 CORS”带来的安全隐患。
- 安装：
pip install flask-cors - 最简全局启用：
from flask import Flask from flask_cors import CORS <p>app = Flask(<strong>name</strong>) CORS(app) # 允许所有源，所有方法
- 限制来源（推荐）：
CORS(app, origins=["https://www.php.cn/link/8e5687e2d6ab87e5da2f833f3e8986a4", "https://myapp.com"]) - 启用凭证支持（必须配对）：
CORS(app, supports_credentials=True)，且前端fetch必须设credentials: 'include' - 针对单个路由：
from flask_cors import cross_origin <p>@app.route('/api/data', methods=['GET', 'POST']) @cross_origin(origins=["<a href="https://www.php.cn/link/8e5687e2d6ab87e5da2f833f3e8986a4">https://www.php.cn/link/8e5687e2d6ab87e5da2f833f3e8986a4</a>"], supports_credentials=True) def get_data(): return {"result": "ok"}
遇到 400 Bad Request 或 credentials 报错时检查这三处
即使加了 flask-cors，仍可能因底层细节出错。重点排查：
立即学习“Python免费学习笔记（深入）”；
-
origins值不能是通配符"*"+supports_credentials=True，否则 Flask-CORS 会静默禁用凭证支持，浏览器报The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' - 前端
fetch的credentials和后端supports_credentials必须严格一致；设了True却没传 cookie，或反之，都会触发 400 - 如果用 Nginx 反向代理 Flask，确保 Nginx 没覆盖或清空了 Flask 返回的 CORS header（尤其
Access-Control-Allow-Origin），可临时关掉 Nginx 直连 Flask 复现验证
真正麻烦的不是加 CORS，而是混合使用代理、凭证、自定义 header 时，各层（前端、Flask、反代、浏览器）对 header 的校验规则不一致。建议先关掉所有代理、用最简 fetch 调用，确认 flask-cors 配置生效后再逐步加复杂度。
