要从根源上理解并解决前端的跨域资源共享问题，核心在于必须首先深刻理解其背后的、作为所有现代浏览器“安全基石”的“同源策略”，并认识到，跨域资源共享机制本身并非一种“限制”，而恰恰是对“同源策略”这道“天然壁垒”的一种“安全、可控的解禁方案”。一个前端开发者之所以会频繁在网络请求中遭遇“跨域错误”，其问题的根源百分之九十九的情况下，都并非出在前端的代码本身，而是因为后端服务器未能正确地配置相关的响应头，来向浏览器明确地“授权”本次跨域请求。
因此，解决这一问题的完整路径必须涵盖五个关键环节：理解“同源策略”这一根本性的安全基石、认识到跨域资源共享是“解禁”而非“限制”的机制、区分“简单请求”与“预检请求”的不同处理流程、在后端正确配置“允许访问的控制源”等响应头、以及在开发环境中使用“代理”作为临时解决方案。其中，理解“同源策略”这一根本性的安全基石，是理解所有跨域问题的大前提。
一、安全基石、浏览器的“同源策略”
在开发者第一次在浏览器的控制台中，看到那段红色的、关于“跨域”的错误信息时，其第一反应常常是：“为什么浏览器要多此一举地来‘限制’我的网络请求？”
这是一个极其普遍但完全错误的“受害者视角”。要真正地从根源上理解跨域问题，我们必须进行一次彻底的“视角转换”，即从“浏览器安全设计者”的视角来重新审视这个问题。
首先需要明确什么是“源”。在网络世界中，一个“源”由协议、域名和端口号这三个部分共同唯一定义。只要这三者其中任何一个不完全相同，那么它们就被视为来自两个“不同的源”。例如，http://example.com 和 https://example.com 因为协议不同而不是同源；http://www.example.com 和 http://api.example.com 因为域名不同而不是同源；http://example.com 和 http://example.com:8080 因为端口号不同而不是同源。
同源策略是所有现代浏览器都必须遵守的、最核心、最基础的“安全策略”。它规定一个源的文档或脚本，默认情况下被禁止与另一个源的资源进行交互。这条看似“不近人情”的规则，其背后是为了保护我们每一个普通用户的最根本的“网络安全”。我们可以想象一个没有同源策略的“危险世界”：你在这个浏览器标签页登录了你的网上银行，在另一个标签页不小心打开了一个恶意网站。如果没有同源策略的保护，那么这个恶意网站页面中的脚本将可以肆无忌惮地向你的网上银行的地址发起网络请求。因为你的浏览器中还保存着你网上银行的登录凭证，所以这个来自恶意网站的请求将能够成功地读取到你所有的银行余额、交易记录，甚至可以在后台模拟你的操作进行“转账”。
同源策略正是为了防止这类“跨站请求伪造”和“跨站脚本”攻击而建立起的一道坚固的“防火墙”。它确保了从A网站来的脚本只能“触摸”A网站的资源，而无法染指B网站的任何东西。
二、破局之道、**跨域资源共享**机制
然而，随着网络应用的发展，不同源之间的“合法”的、被授权的资源共享需求变得越来越普遍，例如一个前端应用需要调用一个独立部署的后端数据接口。为了在不破坏“同源策略”这个安全基石的前提下，满足这种合理的需求，万维网联盟设计了一套标准的、安全的“解禁”机制——这就是“跨域资源共享”。
它的核心思想是一场发生在“浏览器”与“服务器”之间的、关于“权限”的、严谨的“对话”。当浏览器侦测到一个前端脚本正在试图发起一次“跨域”的网络请求时，它并不会立即将这个请求发送出去，而是会先“拦截”下来，并扮演“安保员”的角色。浏览器会替前端向那个“目标服务器”发送一个“问询”：“你好，我这里有一个来自A源的脚本，想要访问你的资源，你是否允许？”
目标服务器在接收到这个“问询”后，会根据自己内部的“安全策略”来做出“决策”。如果服务器允许这次跨域访问，它就会在返回的响应中，添加一个或多个以Access-Control-Allow-开头的“响应头”，来明确地向浏览器“授权”。浏览器在收到服务器的“回答”后，会检查其中的“授权”信息。如果授权信息与本次请求匹配，那么它才会将那个真正的数据请求“放行”出去，并将最终获取到的响应交给前端脚本。如果授权失败，它就会在前端的控制台中抛出那个我们所熟悉的“跨域错误”。
因此，我们必须深刻地理解一点：跨域错误的发生，其“报错”的主体是“浏览器”；但其“犯错”的根源，却几乎总是在于“服务器”，未能正确地配置“授权”。
三、后端服务器的“授权”职责
解决跨域问题的核心在于“后端服务器”的正确配置。后端开发者必须学会如何在自己的应用程序中，正确地添加和管理那一系列以Access-Control-Allow-开头的“授权”响应头。跨域资源共享机制将跨域请求根据其“风险性”，划分为两种不同的处理流程：“简单请求”和“非简单请求”（需要“预检”）。
对于被浏览器判定为“简单请求”的场景，浏览器会采取一种相对“乐观”的、简化的流程。简单请求必须同时满足多个条件，例如请求方法必须是GET、HEAD、POST三者之一，且请求头的类型等也符合特定规范。在这种情况下，浏览器会直接向目标服务器发送这个真实的请求，但在发送时会自动地在请求头中增加一个Origin字段，用以表明“本次请求，源自于何处”。服务器接收到请求后，处理业务逻辑，然后在返回响应时，必须根据请求头中的Origin值来判断，是否要在响应头中增加一个Access-C-ontrol-Allow-Origin字段。浏览器在接收到响应后，会检查是否存在这个响应头，以及其值是否与当前页面的源匹配。如果匹配，则请求成功，数据被交给前端；如果不匹配，则请求被浏览器拦截，前端收到跨域错误。
对于所有不满足“简单请求”条件的请求，例如一个PUT或DELETE方法，或一个请求体为JSON格式的POST请求，浏览器会认为它们是具有“潜在副作用”的、“危险”的请求。因此，在发送“真实”的请求之前，浏览器会先自动地发送一个“投石问路”式的、“咨询性”的请求，这个“先遣”请求被称为“预检请求”。这个预检请求的请求方法永远是OPTIONS，它会包含一些重要的请求头来向服务器“请示”，例如“我接下来准备用PUT方法，带着一个application/json的请求体，来请求你的这个地址，你是否允许？”
服务器必须能够正确地处理这个OPTIONS方法的预检请求。它不应去执行任何业务逻辑，而应立即返回一个响应。在这个响应的“响应头”中，它需要清晰地告知浏览器，它所“允许”的跨域请求的“范围”。浏览器在接收到这个“预检”响应后，会检查其中的“授权范围”，例如Access-Control-Allow-Methods中是否包含了PUT。如果预检“通过”，浏览器才会去发送那个真实的、包含了业务数据的PUT请求。如果预检“失败”，浏览器会直接在控制台报告跨域错误，而那个真实的PUT请求将永远不会被发送出去。
四、前端开发的“正确”实践
虽然解决跨域问题的“钥匙”掌握在后端手中，但前端开发者，也需要具备正确的知识和实践，来配合和应对。
前端开发人员需要确保在发起请求时，正确地配置相关选项。例如，如果一个跨域请求需要携带Cookie等凭证信息，那么，在使用fetch或axios等工具时，必须明确地，将“credentials”这个配置项，设置为'include'。
同时，前端代码必须拥有健壮的错误处理机制。当浏览器因为跨域策略而阻止了一个请求时，它会在程序层面，抛出一个错误。前端的业务逻辑，必须能够捕获到这个错误，并向用户，展示一个清晰、友好的错误提示（例如，“数据加载失败，请检查您的网络连接或稍后重试”），而不是让程序，因为一个未捕获的异常而直接崩溃。
在开发环境中，如果暂时无法或不方便去修改后端的配置，前端开发者可以采用一种名为“代理”的“变通”方案。其核心思想是利用“同源策略”本身。前端应用不再直接请求那个“跨域”的后端接口地址，取而代之，它向自己所在的、同源的“开发服务器”发起一个请求。因为是“同源”的，所以这个请求永远不会被浏览器所拦截。前端的“开发服务器”在接收到这个请求后，会像一个“中间人”一样，在后台将这个请求原封不动地“转发”给那个真实的、跨域的后端接口服务器。后端服务器处理完毕后，将结果返回给“开发服务器”，“开发服务器”再将这个结果返回给前端应用。现代的前端构建工具，都提供了极其简单的、开箱即用的“代理”配置功能，开发者只需在配置文件中增加几行简单的配置即可实现。但需要强调的是，代理是一种“开发时”的、用于提升效率的“辅助”手段，它并不能解决生产环境中的跨域问题。
五、系统性的“诊断”与“协同”
当一个跨域错误，真实地发生时，我们需要一套系统性的“诊断”流程，来快速地，定位问题的根源。
第一步，也是最重要的一步，是使用浏览器开发者工具。“网络”面板，是所有前后端接口调试的“第一案发现场”。我们需要找到那条失败的请求，并仔细地，检查其相关的“预检请求”和“真实请求”。检查预检请求的响应头，Access-Control-Allow-Methods是否包含了我们正在使用的方法？检查真实请求的响应头，Access-Control-Allow-Origin的值，是否正确地，包含了我们前端应用的“源”？
第二步，是使用接口测试工具。使用Postman等工具，可以脱离前端代码和浏览器的“同源策略”限制，直接地，对接口，进行调用和测试。如果一个请求，在Postman中，能够成功返回数据，但在浏览器中，却报“跨域错误”，那么，我们就可以100%地确定，这是一个纯粹的、需要由后端，来配置响应头解决的跨域问题。
最后，必须强调，解决跨域问题，是一个需要“前后端”紧密“协同”的过程。前端开发者，在遇到问题时，不应只是抱怨，而应清晰地，向后端开发者，提供导致错误的、完整的请求信息。而后端开发者，也应将“正确配置跨域策略”，视为接口开发规范中，一个不可或`缺的组成部分。
常见问答 (FAQ)
Q1: 什么是“同源策略”？
A1: “同源策略”，是浏览器的一个核心安全功能，它限制了，从一个“源”（由协议、域名、端口共同定义）加载的文档或脚本，如何与来自另一个“源”的资源，进行交互。这是为了防止恶意的跨站攻击。
Q2: 为什么我的标签加载跨域资源，没有遇到跨域问题？
A2: 因为，“同源策略”，主要限制的是“脚本”所发起的“可读写”的网络请求。而对于一些特定的、能够被HTML标签直接加载的资源（如图片、样式表、脚本文件），浏览器，出于“可用性”的考量，是允许它们进行“跨域”加载的，但这通常，也伴随着一些安全上的限制。
Q3: 我在后端已经设置了“允许访问的控制源”为*，为什么带凭证的请求还是失败了？
A3: 这是由安全规范所决定的。如果，一个跨域请求，需要携带“凭证”（例如，Cookie），那么，出于安全考虑，服务器，在返回的Access-Control-Allow-Origin响应头中，绝不能，使用*这个通配符。它必须，明确地，指定那个唯一的、被允许的源地址。
Q4: 什么是“预检请求”？它有什么用？
A4: “预检请求”，是在发送一个“非简单”的（例如，PUT或DELETE方法，或带有自定义请求头）的跨域请求之前，由浏览器，自动发起的、一次使用OPTIONS方法的“探路”或“问询”请求。它的作用，是提前地，向服务器，确认，后续的那个“真实”的请求，是否是被允许的，从而，保障了服务器的安全。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：百晓生，转转请注明出处：https://www.chuangxiangniao.com/p/638867.html
微信扫一扫 
支付宝扫一扫 
