在当今的Web开发世界中，前后端分离架构已成为主流，前端应用通过AJAX（Asynchronous JavaScript and XML）技术向后端API请求数据，动态渲染页面，许多开发者都曾遭遇过一个令人头疼的浏览器控制台报错：“Access to XMLHttpRequest at ‘…’ from origin ‘…’ has been blocked by CORS policy…”，这便是著名的“AJAX跨域报错”，要彻底解决它,我们必须深入其背后的核心机制。
探究根源：同源策略
这个报错的始作俑者并非AJAX本身，而是浏览器一个至关重要的安全基石——同源策略，所谓“同源”，指的是两个URL的协议、域名和端口三者完全相同，同源策略的核心思想是，一个源的文档或脚本，不能读取或修改另一个源的文档属性,这是一种隔离潜在恶意文档的安全措施。
为了更直观地理解，我们可以看下面的表格，假设当前页面源是 http://www.example.com/dir/page.html：
| URL | 是否同源 | 原因 |
|---|---|---|
http://www.example.com/dir2/other.html | 是 | 协议、域名、端口均相同 |
http://www.example.com:81/dir/page.html | 否 | 端口不同 (80 vs 81) |
https://www.example.com/dir/page.html | 否 | 协议不同 (http vs https) |
http://en.example.com/dir/page.html | 否 | 域名不同 |
当我们的前端应用（例如运行在 http://localhost:3000）尝试通过AJAX请求一个不同源的API（https://api.service.com/data）时，浏览器就会拦截这个请求的响应，并抛出跨域错误，这并非请求没有发送出去，服务器通常也正常处理并返回了数据，但浏览器出于安全考虑,阻止了JavaScript代码访问这个响应内容。
跨域解决方案的“十八般武艺”
既然同源策略是浏览器的“硬性规定”，我们该如何在需要跨域通信的场景下“合法合规”地实现数据交互呢？业界已经发展出多种成熟的解决方案。
CORS（跨域资源共享）——官方标准
CORS是W3C推荐的标准，也是目前最主流、最安全的跨域解决方案，它允许服务器在HTTP响应头中声明哪些外部源可以访问其资源，整个过程由浏览器自动完成,对于前端开发者来说几乎是透明的。
实现CORS的关键在于服务器端的配置,服务器需要添加一个或多个特定的HTTP响应头：
Access-Control-Allow-Origin: 这是最重要的头部，它的值可以是允许访问的源（如https://www.myapp.com），也可以是通配符 ，表示允许任何源访问，但在生产环境中，出于安全考虑，不建议使用 。Access-Control-Allow-Methods: 指定允许的HTTP方法，如GET, POST, PUT, DELETE。Access-Control-Allow-Headers: 指定允许的请求头，如Content-Type, Authorization。Access-Control-Allow-Credentials: 当前端需要携带Cookie时，需将其设为true，且Access-Control-Allow-Origin不能为 。
对于某些“非简单请求”（如使用 PUT 方法或 Content-Type 为 application/json 的 POST 请求），浏览器会在发送真实请求前，自动发送一个“预检请求”，使用 OPTIONS 方法询问服务器是否允许该跨域请求，服务器必须正确响应这个预检请求,真实的业务请求才能被发送。
JSONP（JSON with Padding）——巧妙的前端“伎俩”
在CORS普及之前，JSONP是一种流行的跨域解决方案，它利用了 <script> 标签不受同源策略限制的特性，其原理是：前端动态创建一个 <script> 标签，其 src 属性指向跨域API的URL，并附带一个回调函数名，服务器接收到请求后，会将数据作为参数填充到这个回调函数中，返回一段可执行的JavaScript代码，前端收到响应后，这段代码会立即执行，从而触发回调函数,获取数据。
JSONP的缺点非常明显：
- 仅支持GET请求：因为
<script>标签只能发起GET请求。 - 安全性较差：容易受到XSS（跨站脚本攻击）的威胁,因为返回的是可执行代码。
- 错误处理困难：无法像XHR一样检测请求失败的状态。
除非是与不支持CORS的古老服务进行对接,否则已不推荐使用JSONP。
代理服务器——绕过浏览器限制
这是一种非常灵活且强大的方案，特别适用于开发环境，其核心思想是：浏览器不直接请求目标API，而是请求一个与自己同源的代理服务器（通常由后端语言或Node.js搭建），再由这个代理服务器去请求真正的跨域API,最后将结果返回给前端。
在这个过程中，跨域发生在服务器与服务器之间，而服务器之间的通信不受同源策略限制，对于浏览器来说，它始终是在和同源的服务器打交道，因此不会触发跨域报错，在开发中，webpack-dev-server 就内置了非常方便的代理配置功能，在生产环境中,也可以使用Nginx等反向代理服务器实现同样的效果。
如何选择合适的方案？
选择哪种方案取决于具体场景：
- 如果你能控制后端服务器：CORS是毫无疑问的首选,它是现代Web的标准实践。
- 如果你无法控制后端，且对方是公共API：查阅其文档,看它是否支持CORS或提供JSONP接口。
- 如果你在开发环境中，且后端暂时无法配置CORS：使用代理服务器是最高效的解决方案。
相关问答FAQs
问题1：为什么在我的本地开发环境（localhost:3000 访问 api.example.com）也会出现跨域问题？
回答： 这是因为“同源策略”的判断标准是严格的协议、域名和端口三元组，即使 localhost:3000 和 api.example.com 都是你自己的开发环境，但在浏览器看来，它们的域名（localhost vs api.example.com）完全不同，因此属于跨域，浏览器无法区分这是本地开发还是恶意网站,所以会一视同仁地执行同源策略。
*问题2：我已经在后端设置了 `Access-Control-Allow-Origin: `，为什么前端还是报跨域错误？**
回答： 这是一个常见问题，即使设置了 ,跨域错误仍可能由以下原因导致：
- 请求携带了凭证：如果你的AJAX请求设置了
withCredentials: true（用于携带Cookie等认证信息），那么服务器不能使用通配符 ，必须明确指定一个具体的源，如Access-Control-Allow-Origin: http://localhost:3000，并且需要同时设置Access-Control-Allow-Credentials: true。 - 非简单请求的预检失败：如果你的请求是“非简单请求”（
Content-Type为application/json的POST请求），浏览器会先发送一个OPTIONS方法的“预检请求”，你的服务器必须能够正确响应这个OPTIONS请求，并返回上述允许的头部信息，如果服务器没有处理OPTIONS请求，或者返回的头部信息不完整，预检就会失败,导致真实请求无法发出。 - 其他响应头冲突：确保服务器没有返回多个或冲突的
Access-Control-Allow-Origin头部,缓存插件或服务器配置错误可能导致这种情况。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
发表回复