Flask 默认不处理跨域，需用 Flask-CORS 插件全局配置：安装后两行代码 CORS(app) 即可启用，开发用 origins=""，生产须指定可信源且 credentials 与 不共存。
Flask 默认不处理跨域，浏览器直接拦截请求
Vue 启在 http://localhost:5173，Flask 启在 http://localhost:5000，哪怕后端返回了正确数据，前端 fetch 或 axios 也会卡在预检（OPTIONS）或直接报 CORS error。这不是 Flask 写错了，是它压根没发 Access-Control-Allow-Origin 这类响应头——浏览器按同源策略默认拒绝。
常见错误现象：Failed to fetch、No 'Access-Control-Allow-Origin' header、控制台看到 OPTIONS 请求 404 或 200 但后续 POST/GET 被 block。
- 别手动在每个路由加
make_response和 headers，维护成本高且容易漏 - 别用 Nginx 反向代理绕过（开发阶段没必要，掩盖问题）
- 别改浏览器安全策略（本地调试都做不到，纯误导）
pip install Flask-CORS 是最稳的解法
Flask-CORS 不是“可选插件”，是专为 Flask 设计的跨域中间件，兼容性好、配置粒度细、不污染业务逻辑。
安装后只需两行代码：
from flask import Flask from flask_cors import CORS <p>app = Flask(<strong>name</strong>) CORS(app) # 全局开启，允许所有源</p>
这样就能让所有路由响应带上 Access-Control-Allow-Origin: * 等必要头。
- 如果只允许特定前端地址，传
origins=["http://localhost:5173"] - 需要带 cookie 或认证头时，必须加
supports_credentials=True，且前端 fetch 要设credentials: "include" -
resources参数可做路径级控制，比如resources={r"/api/*": {"origins": "https://myapp.com"}}
为什么不用 @cross_origin 装饰器？
@cross_origin 看起来轻量，但实际容易踩坑：
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
- 装饰器只作用于被修饰的函数，漏写一个路由就跨域失败，尤其后期加新接口时极易遗忘
- 无法统一控制 credentials、headers、methods 等全局行为，每个装饰器都要重复写参数
- 和蓝图（Blueprint）配合时，若在 blueprint 外层用
@cross_origin，可能不生效；若每个视图里都加，代码冗余爆炸 - 某些复杂场景（如 Flask-RESTful 的 Resource 类）装饰器支持不稳定
除非你明确只要某 1–2 个接口开放跨域，其余全部禁止，否则优先走 CORS(app) 全局初始化。
开发环境开全通，生产环境必须收口
本地调试时设 CORS(app, origins="*") 没问题，但部署到生产环境后，origins="*" 和 supports_credentials=True 不能共存——浏览器会直接拒绝，这是规范强制要求。
所以生产配置必须明确指定可信源：
CORS(app,
origins=["https://yourdomain.com", "https://admin.yourdomain.com"],
supports_credentials=True)
另外注意：Flask-CORS 不处理 HTTPS 证书、Nginx 转发头丢失等问题。如果上线后仍有跨域失败，先确认请求真正到达了 Flask（看日志），再查反向代理是否覆盖或清除了 CORS 响应头。
真正的麻烦点不在怎么开，而在什么时候关、关多少——尤其是多子域、灰度发布、微前端嵌套这些场景，origins 列表得跟着部署策略动态变，硬编码在这里很容易拖垮协作节奏。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
