CORS配置失效的常见原因包括：代码顺序错误（CORS(app)须在路由注册前）、蓝图未单独注册、多进程热重载导致配置未同步、Nginx未透传响应头、origins设为"*"却启用credentials、预检OPTIONS未正确处理。
CORS 配置不是“开了就完事”，它经常在你没注意的地方失效 —— 大部分报错根本不是插件没装，而是它压根没管到那个请求。
为什么 CORS(app) 写了却没生效
最常见的情况是：代码顺序错了。比如把 CORS(app) 放在所有 @app.route 之后，或者放在 if __name__ == '__main__': 里；又或者用了蓝图但没对蓝图注册 CORS。
-
CORS(app)必须在路由注册前执行，否则只作用于后续新增的路由（而你的已有路由已注册完毕） - 如果用蓝图，
CORS(app)不会自动覆盖蓝图内的视图，得单独对蓝图调用CORS(blueprint)或用@cross_origin装饰器 - 开发时开启
debug=True可能触发多进程热重载，改完配置只加载到一个进程，另一个旧进程还在跑，导致“改了但没生效” - 部署在 Nginx/uWSGI 时，Nginx 默认不透传自定义响应头，
Access-Control-Allow-Origin被直接吞掉，浏览器根本收不到
origins 白名单不能写 "*" 就完事
只要前端带 cookie、Authorization 头，或后端设了 supports_credentials=True，origins="*" 就立刻失效 —— 浏览器会直接拒绝响应，连预检都过不去。
- 开发阶段明确列出前端地址：
origins=["http://localhost:3000", "http://127.0.0.1:3000"] - 生产环境必须用完整 HTTPS 域名，不含端口：
origins=["https://myapp.com", "https://admin.myapp.com"] - Electron/WebView 场景可加
"file://"，但仅限本地可信环境 - 正则匹配如
r"https?://(localhost|myapp)\.com(:\d+)?"容易漏转义或过度匹配，调试时建议先用静态列表，确认通了再换正则
POST 请求发不出去？大概率卡在 OPTIONS 预检
Axios、fetch 发 Content-Type: application/json 时，浏览器强制走预检（OPTIONS），如果后端没正确响应这个 OPTIONS 请求，后续 POST 根本不会发出。
- 别手动写
@app.route("/xxx", methods=["OPTIONS"])—— 这会覆盖flask-cors自带的 OPTIONS 处理逻辑 - 确保
methods参数包含"OPTIONS"：CORS(app, methods=["GET", "POST", "PUT", "DELETE", "OPTIONS"]) - 若用
@cross_origin装饰器，同样要显式传methods，例如：@cross_origin(origins=["http://localhost:3000"], methods=["POST", "OPTIONS"]) - 检查浏览器开发者工具 Network 标签页，看第一个请求是不是 OPTIONS，状态码是否为 200，响应头里有没有
Access-Control-Allow-Origin
部署后 CORS 失效，先查反向代理是否吃掉了响应头
Nginx 默认不转发自定义响应头，flask-cors 设置的 Access-Control-* 全部被丢弃，浏览器收不到任何跨域许可头。
立即学习“Python免费学习笔记（深入）”；
- Nginx 配置里必须加：
add_header 'Access-Control-Allow-Origin' 'https://myapp.com' always;（注意always，否则 4xx/5xx 响应不生效） - 同时补上：
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;和add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization' always; - 如果后端已配
supports_credentials=True，Nginx 还得加：add_header 'Access-Control-Allow-Credentials' 'true' always; - 更稳妥的做法是：让 Nginx 处理 CORS，后端关掉
flask-cors，避免两层头冲突
