Flask中加装饰器仍报错主因是预检OPTIONS请求未被处理，需全局配置CORS或手动注册OPTIONS路由；DRF需用djangorestframework-cors插件分三层控制；FastAPI的CORSMiddleware要求路径存在且无中间件阻断；部署后失败多因Nginx等代理未透传响应头。
Flask 中用 flask-cors 时为什么加了装饰器还是报错？
常见错误是只在单个路由上加 @cross_origin()，但前端发的是预检请求（OPTIONS），而该路由没定义或没被拦截。Flask 默认不自动响应 OPTIONS，除非你显式注册、用 app.add_url_rule() 手动挂载，或者更稳妥地——全局启用。
- 全局启用：初始化时传参，比如
CORS(app, resources={r"/api/*": {"origins": "<a href="https://www.php.cn/link/8e5687e2d6ab87e5da2f833f3e8986a4">https://www.php.cn/link/8e5687e2d6ab87e5da2f833f3e8986a4</a>"}}) - 装饰器只对带
@app.route的函数生效，对蓝图（Blueprint）需单独初始化CORS(blueprint, ...) - 如果用了 Nginx 或其他反向代理，确保它没过滤掉
Access-Control-Request-*请求头
Django REST Framework 怎么避免重复配置 CORS_ALLOWED_ORIGINS 和视图级控制？
DRF 本身不处理 CORS，靠 djangorestframework-cors 插件。它的配置粒度分三层：全局（settings.py）、视图类（permission_classes 不管用，得靠 @cors_allow_all 或自定义 mixin）、视图方法（极少用）。容易踩的坑是：
-
CORS_ALLOWED_ORIGINS是白名单，写["*"]仅适用于开发；生产环境必须写具体域名，否则浏览器拒绝凭据（credentials=True） - 启用
CORS_ALLOW_CREDENTIALS = True时，CORS_ALLOWED_ORIGINS不能含通配符"*"，否则整个中间件静默失效 - 若部分接口要放行所有来源（如公开文档页），用
CORS_URLS_REGEX = r'^/public/.<em>$'</em>配合CORS_ALLOWED_ORIGINS = [""]更安全
FastAPI 的 add_middleware(CORSMiddleware) 为什么 OPTIONS 请求返回 405？
FastAPI 的 CORSMiddleware 会自动处理预检请求，但前提是：路径必须真实存在，且没有其他中间件提前终止了请求流。典型问题包括：
- 路由未定义（比如访问
/api/v1/users，但只写了/api/users），导致 404，预检失败 - 在
CORSMiddleware之前挂了自定义中间件，且该中间件对OPTIONS没做透传或返回空响应 -
allow_origins设为["*"]但同时设了allow_credentials=True→ 直接抛ValueError，启动就失败
正确写法示例：
app.add_middleware( CORSMiddleware, allow_origins=["<a href="https://www.php.cn/link/8e5687e2d6ab87e5da2f833f3e8986a4">https://www.php.cn/link/8e5687e2d6ab87e5da2f833f3e8986a4</a>"], allow_credentials=True, allow_methods=["<em>"], allow_headers=["</em>"], )
为什么本地开发能过，部署到服务器后跨域又失败？
不是代码问题，大概率是部署层“吃掉”了关键响应头。Nginx 默认不转发后端写的 Access-Control-Allow-Origin，除非你显式允许：
立即学习“Python免费学习笔记（深入）”；
- 确保 Nginx 配置里有
add_header 'Access-Control-Allow-Origin' '<a href="https://www.php.cn/link/89a8a462f5d9555ff8df960ea08d60dc">https://www.php.cn/link/89a8a462f5d9555ff8df960ea08d60dc</a>' always;（注意always，否则 4xx/5xx 响应不带） - 如果后端已写头，Nginx 又重写了同名头，以前者为准；但多数情况是 Nginx 完全屏蔽了后端头，得用
proxy_pass_request_headers on; - Cloudflare 等 CDN 可能缓存了预检响应，导致新配置不生效，临时关闭缓存或清掉
OPTIONS缓存
CORS 的真正复杂点不在怎么配，而在于每层（前端发什么、Web 服务器怎么转、应用框架怎么回、反向代理怎么透传）都可能悄悄改掉一个头，漏掉一层，就卡在预检阶段不动。
