cors(app)未生效主因是初始化顺序错误、蓝图未单独注册、预检options响应缺失或nginx吞头；必须在app创建后、路由注册前执行，蓝图需显式调用cors(blueprint)，且nginx须透传access-control-allow-*头。
Flask 的 CORS 报错不是插件没装，而是 flask-cors 没真正管到那个请求——90% 的问题出在初始化时机、蓝图遗漏、预检响应缺失或反向代理吞头。
为什么 CORS(app) 写了却没生效
最常见原因是它被放在了所有 @app.route 之后，或者塞进了 if __name__ == '__main__': 块里。Flask-CORS 只会对它执行之后注册的路由生效；而你的视图函数早已注册完毕，插件根本没接管过去。
-
CORS(app)必须紧跟在app = Flask(__name__)后面，且在任何@app.route或register_blueprint()之前 - 用了蓝图（
Blueprint）？CORS(app)不会自动覆盖蓝图内的路由，必须显式调用CORS(my_blueprint)或对单个函数加@cross_origin() - 开发时开了
debug=True？热重载可能启了多个进程，改完配置只加载进一个，另一个旧进程还在跑——重启整个服务才能确认是否真生效
origins="*" 和 supports_credentials=True 互斥
只要前端发请求时带了 credentials: 'include'（比如传 cookie 或 Authorization 头），浏览器就会直接拒绝响应，连错误细节都不给全，控制台只显示模糊的 “CORS error”。
- 开发阶段用明确列表：
origins=["http://localhost:3000", "http://127.0.0.1:3000"] - 生产环境必须写完整 HTTPS 域名，不含端口：
origins=["https://myapp.com", "https://admin.myapp.com"] - 如果必须支持凭据，
origins不能是"*"，且响应头中必须有Access-Control-Allow-Credentials: true
POST/PUT/DELETE 卡在 OPTIONS 预检
Axios 或 fetch 发 Content-Type: application/json 时，浏览器强制走预检（OPTIONS 请求）。如果后端没正确响应这个 OPTIONS，真实请求根本不会发出。
- 别手动写
@app.route("/xxx", methods=["OPTIONS"])——这会覆盖flask-cors自带的处理逻辑 - 全局配置要显式包含
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-Methods和Access-Control-Allow-Headers
Nginx/uWSGI 部署后 CORS 失效
本地跑得好好的，一上服务器就跨域失败——大概率是 Nginx 把 Access-Control-Allow- 开头的响应头直接吞掉了，浏览器根本收不到。
- Nginx 配置中必须显式透传这些头：
add_header 'Access-Control-Allow-Origin' '$sent_http_access_control_allow_origin' always;（注意always，否则不作用于 4xx/5xx 响应） - 还要透传其他关键头：
add_header 'Access-Control-Allow-Methods' '$sent_http_access_control_allow_methods' always;、add_header 'Access-Control-Allow-Headers' '$sent_http_access_control_allow_headers' always; - 如果用了 uWSGI，确认
uwsgi_pass后没有额外的中间层过滤响应头
真正难调试的点往往不在代码本身，而在启动顺序、蓝图边界、预检响应完整性、以及反向代理对响应头的静默截断——这几个地方漏掉任何一个，flask-cors 就等于没配。
