flask中cors(app)未生效主因是配置未实际接管路由：顺序错误（须在@app.route前）、蓝图未单独注册cors、多进程热重载导致配置不同步、nginx吞掉响应头、或origins="*"与supports_credentials=true混用致预检失败。
直接在后端加响应头就能让浏览器放行跨域请求，但错一处就白配——Access-Control-Allow-Origin没返回、OPTIONS预检失败、credentials和*混用，都会导致前端报红。
Flask 中 CORS(app) 为什么写了却没生效
最常见的是代码顺序和作用域问题：CORS 配置必须在所有路由注册前执行，否则只对之后定义的路由起作用。
-
CORS(app)放在@app.route之后？它压根没管到你的接口 - 用了蓝图（
Blueprint）但只调了CORS(app)？蓝图里的路由不受影响，得单独写CORS(blueprint)或用@cross_origin装饰器 - 开发时开了
debug=True？uWSGI 或 Flask 自带热重载可能启多个进程，改完配置只加载进一个进程，另一个还在跑旧逻辑 - 部署在 Nginx 后面？Nginx 默认不透传自定义响应头，
Access-Control-Allow-Origin被 silently 吞掉，浏览器根本收不到
FastAPI 的 CORSMiddleware 配置要点
FastAPI 的中间件是全局生效的，但参数含义容易误解，尤其 allow_credentials 和 allow_origins 是强绑定关系。
-
allow_origins=["*"]和allow_credentials=True不能共存——浏览器会直接拒绝响应，连预检都过不去 - 带 cookie 或 Authorization 头的请求，必须显式列出前端地址，比如
["http://localhost:3000", "https://myapp.com"]
allow_methods=["*"] 看似方便，但某些网关或 CDN 会过滤掉 <code>*，建议明确写["GET", "POST", "PUT", "DELETE", "OPTIONS"]-
max_age=3600控制预检缓存时间，设太小会导致频繁发OPTIONS，设太大则改了策略不及时生效
预检请求（OPTIONS）失败的典型表现
前端发 POST 带 Content-Type: application/json，但 Network 面板里第一个请求就是 OPTIONS 且状态码不是 200，后续真实请求根本不会发出。
- 别手动写
@app.route("/xxx", methods=["OPTIONS"])—— 这会覆盖flask-cors或CORSMiddleware内置的预检处理逻辑 - 确保
methods参数包含"OPTIONS"，例如CORS(app, methods=["GET", "POST", "OPTIONS"]) - 用
@cross_origin装饰器时，也要显式传methods=["POST", "OPTIONS"]，否则预检被忽略 - 检查响应头是否真有
Access-Control-Allow-Methods和Access-Control-Allow-Headers，缺一不可
真正卡住人的地方往往不是“怎么配”，而是“配给谁”——你得确认那个报错的请求，到底走的是哪个路由、经过的是哪个中间件、有没有被反向代理截胡。调试时先看 Network 里 OPTIONS 请求的响应头，再比对服务端实际输出，比瞎改配置快得多。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
