Flask框架如何处理跨域资源共享请求_Python集成Flask-CORS配置-Python教程-PHP中文网

flask默认拒绝跨域请求，需用flask-cors扩展显式启用cors；它自动处理预检、凭证传递和头白名单，避免手动配置遗漏或错误。

flask框架如何处理跨域资源共享请求_python集成flask-cors配置

Flask 默认拒绝跨域请求，必须显式启用 CORS

浏览器对非同源请求（协议、域名、端口任一不同）会拦截响应，即使后端已返回数据。Flask 本身不处理 Access-Control-Allow-Origin 等响应头，直接返回 200 并不等于前端能读取响应。必须通过中间件或装饰器注入 CORS 头，否则前端 fetch 或 axios 会报 TypeError: Failed to fetch 或控制台显示 “CORS header ‘Access-Control-Allow-Origin’ missing”。

用 Flask-CORS 扩展最稳妥，避免手写响应头出错

手动在每个路由加 make_response 并设置头容易遗漏、重复或覆盖错误（比如忘记带 credentials 相关头）。Flask-CORS 封装了 W3C CORS 规范细节，自动处理预检（OPTIONS）、凭证传递、头白名单等边界情况。

安装与基础用法：

pip install flask-cors

全局启用（开发常用）：

from flask import Flask
from flask_cors import CORS
<p>app = Flask(<strong>name</strong>)
CORS(app)  # 允许所有源，所有方法，所有头</p>

生产环境应限制范围：

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

只允许特定域名：CORS(app, origins=["https://myapp.com"])
支持 Cookie/Authorization：CORS(app, supports_credentials=True)，此时 origins 不能为 *，必须指定确切域名
只对部分蓝图启用：CORS(my_blueprint)，避免暴露管理接口

遇到 OPTIONS 预检失败？检查是否漏配 methods / headers

当请求含自定义头（如 X-Auth-Token）或非简单方法（PUT/DELETE），浏览器先发 OPTIONS 请求。若后端未返回正确的 Access-Control-Allow-Methods 或 Access-Control-Allow-Headers，预检失败，后续请求根本不会发出。

常见配置疏漏：

CORS(app, methods=["GET", "POST", "PUT", "DELETE"]) —— 不写 methods 参数时默认只含 GET/HEAD/POST，缺 PUT/DELETE 会导致 405
CORS(app, allow_headers=["Content-Type", "X-Auth-Token"]) —— 前端带了自定义头但后端没声明，预检返回 403
使用 @cross_origin 装饰器时，参数需和全局配置一致，否则局部配置会覆盖全局，引发不一致

调试 CORS 问题优先看 Network 面板的 OPTIONS 请求响应头

不要只盯着主请求的响应体。打开浏览器开发者工具 → Network → 找到类型为 OPTIONS 的请求 → 查看 Response Headers：

是否有 Access-Control-Allow-Origin？值是否匹配前端域名？
是否有 Access-Control-Allow-Credentials: true？且 Access-Control-Allow-Origin 不是 *？
Access-Control-Allow-Methods 是否包含你实际用的 HTTP 方法？
Access-Control-Allow-Headers 是否列出前端发送的所有非简单头？

如果 OPTIONS 返回 200 但头缺失，说明 Flask-CORS 未生效（比如初始化顺序错：必须在注册路由前调用 CORS(app)）；如果返回 404，可能是路由未覆盖 OPTIONS 方法（Flask-CORS 会自动注册，除非你禁用了它）。

真正麻烦的是多个中间件叠加时的头冲突，比如同时用了 Nginx 和 Flask-CORS，或者自己写了 @after_request 设置头 —— 这时候得逐层确认谁在写、谁在覆盖。