内容摘要：CORS目标站点限制，本质上是浏览器替你做的一道安全判断题。它判定“这个网页里的JS，能不能去读另一个域名返回的数据”。后端配了`Access-Control-Allow-Origin`，前端才能拿到

CORS目标站点限制，目标本质上是站点浏览器替你做的一道安全判断题。它判定“这个网页里的限制JS，能不能去读另一个域名返回的解决数据”。后端配了`Access-Control-Allow-Origin`，目标前端才能拿到响应体，站点否则请求发出去了，限制但浏览器把数据拦在门外，解决控制台报红。目标

解决思路分两条路：改后端，站点或者绕前端。限制

先说最直接的解决办法——后端加响应头。你只需要在目标站点的目标响应里加一行：

Access-Control-Allow-Origin: https://你的前端域名 

如果接口不涉及Cookie，用`*`通配符也行，站点省事。限制但如果带`withCredentials`，`*`就失效了，必须写死具体域名，还得额外加`Access-Control-Allow-Credentials: true`。这活儿通常要找对方后端同事，或者你自己能改服务器配置就直接改。

问题在于，很多场景下你根本碰不到目标站点的服务器。比如调第三方公开API，或者公司内部老系统没人维护。这时候就得换思路。

一个常见做法是走代理。你把自己的后端当成中转站，前端请求你的域名，你的后端去请求目标站点，拿到数据后再返回给前端。因为CORS限制只存在于浏览器环境，服务器之间的HTTP请求没有这个约束。具体实现很简单，Nginx里加一段反向代理配置就行：

location /api/ {  proxy_pass https://目标站点.com/; add_header Access-Control-Allow-Origin *; } 

前端把请求地址改成你的域名，问题直接消失。这个方案最稳，也最推荐，因为顺带解决了跨域携带Cookie的麻烦——你可以在代理层手动处理。

还有一种野路子，用JSONP。原理是利用`