在现代 Web 开发中，跨域资源共享（CORS）策略是一个无法回避的话题，许多开发者在使用浏览器（尤其是谷歌 Chrome）进行前后端联调时，都曾在控制台里遇到过那鲜红的“跨域报错”信息，这个错误提示通常以“Access-Control-Allow-Origin”开头，让人初看之下感到困惑，这并非一个 Bug，而是浏览器一项至关重要的安全机制，理解其工作原理并掌握解决方案，是每一位 Web 开发者的必备技能。
什么是跨域与同源策略？
要理解跨域报错，首先必须明白什么是“源”以及“同源策略”。
源由三个部分组成：协议（如 http、https）、域名（如 www.example.com）和端口（如 80、443），只有当这两个请求的协议、域名和端口完全相同时，它们才属于同源。https://www.example.com:443/page1.html 和 https://www.example.com:443/page2.html 是同源的。
同源策略是浏览器最核心也是最基本的安全功能，它规定，一个源的文档或脚本，不能读取或修改另一个源的文档属性，想象一下，如果没有同源策略，你在浏览器中打开了一个恶意网站 A，它就可以肆意读取你同时打开的网上银行网站 B 的信息,后果不堪设想。
当请求的目标资源与当前页面不属于同一个源时，就构成了跨域,下表清晰地展示了同源与跨域的判断：
| 当前页面 URL | 目标 URL | 是否同源 | 原因 |
|---|---|---|---|
http://www.example.com/dir/ | http://www.example.com/dir2/ | 是 | 协议、域名、端口均相同 |
http://www.example.com/dir/ | https://www.example.com/dir/ | 否 | 协议不同 (http vs https) |
http://www.example.com/dir/ | http://api.example.com/dir/ | 否 | 域名不同 (www.example.com vs api.example.com) |
http://www.example.com:80/ | http://www.example.com:8080/ | 否 | 端口不同 (80 vs 8080) |
CORS 报错为何发生？
CORS（Cross-Origin Resource Sharing）机制是同源策略的“补充”，它允许服务器声明哪些外部源可以访问其资源，整个流程的关键在于浏览器和服务器之间的交互。
当浏览器发现一个跨域请求时，它并不会直接发送业务请求（如 GET、POST）,而是先遵循以下规则：
- 简单请求：对于某些符合特定条件的请求（如使用
GET、HEAD、POST方法，且自定义头信息有限），浏览器会直接发送请求，并在请求头中附带一个Origin字段,告知服务器请求来自哪个源。 - 非简单请求：对于更复杂的请求（如使用
PUT、DELETE方法，或包含Content-Type: application/json等自定义头），浏览器会先发送一个“预检请求”，即OPTIONS方法的请求，用于询问服务器是否允许该跨域请求，这个预检请求会包含Origin、Access-Control-Request-Method和Access-Control-Request-Headers等头信息。
服务器的响应是决定性的，如果服务器允许该跨域请求,它的响应头中必须包含以下信息：
Access-Control-Allow-Origin：必须包含请求头中的Origin值，或者设置为 （表示允许所有源，但有限制）。- 对于非简单请求，响应头还需包含
Access-Control-Allow-Methods（允许的方法）和Access-Control-Allow-Headers（允许的头信息）。
如果浏览器在预检请求或真实请求的响应中，没有找到正确的许可信息，就会拦截响应数据，并在控制台抛出我们常见的谷歌跨域报错，报错的核心信息是：“The response had HTTP status code 404” 或 “No ‘Access-Control-Allow-Origin’ header is present on the requested resource.”，这明确指出服务器端没有正确配置 CORS。
如何解决 CORS 问题？
解决了“为什么”，接下来就是“怎么办”，解决 CORS 问题，根本手段在于服务器端的配置,客户端的任何操作都只是绕过或临时方案。
服务器端配置（推荐）
这是最正规、最安全的做法，开发者需要在后端服务器中添加响应头,以明确告知浏览器许可策略。
下表列出了关键的 CORS 响应头及其作用：
| 响应头 | 作用 |
|---|---|
Access-Control-Allow-Origin | 指定允许的源，可以是具体的 https://example.com 或通配符 。 |
Access-Control-Allow-Methods | 指定允许的 HTTP 方法，如 GET, POST, PUT, DELETE。 |
Access-Control-Allow-Headers | 指定允许的请求头，如 Content-Type, Authorization。 |
Access-Control-Allow-Credentials | 是否允许浏览器发送包含凭据（如 Cookies、Authorization 头）的请求，值为 true 或 false。 |
Access-Control-Max-Age | 预检请求的结果可以被缓存多久（秒），减少不必要的 OPTIONS 请求。 |
不同后端语言的配置示例如下：
Node.js (Express):
const express = require('express');
const app = express();
const cors = require('cors');
// 允许所有源
app.use(cors());
// 或者自定义配置
app.use(cors({
origin: 'https://your-frontend-domain.com',
methods: ['GET', 'POST'],
allowedHeaders: ['Content-Type', 'Authorization'],
credentials: true
})); Nginx 配置:
location / {
add_header 'Access-Control-Allow-Origin' 'https://your-frontend-domain.com';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
# 处理预检请求
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain; charset=utf-8';
add_header 'Content-Length' 0;
return 204;
}
} 客户端/开发环境临时方案
在开发阶段，如果无法快速修改服务器配置,可以采用一些临时方案。
- 浏览器插件：安装允许 CORS 的浏览器插件（如 “Allow CORS: Access-Control-Allow-Origin”），一键禁用同源策略。注意：仅限开发环境使用，日常浏览会带来安全风险。
- 代理服务器：在开发服务器（如 Vue CLI, Create React App）中配置代理，所有发往
api.example.com的请求，都由开发服务器转发，浏览器访问的是同源的代理服务器，从而绕过跨域限制,这是最推荐的本地开发方案。
相关问答 FAQs
问题 1：为什么我在 Postman 或其他 API 工具里能正常请求接口，但在浏览器里就报 CORS 错误？
解答： 这是因为 Postman、Insomnia 等专业的 API 测试工具不属于浏览器环境，它们不强制执行同源策略，同源策略是浏览器为保护用户安全而设立的一种“沙盒”机制，当你直接使用这些工具发送请求时，它们就像是绕过了这个安全检查，直接与服务器通信，而浏览器在发送跨域请求时，会严格遵守 CORS 规范，如果服务器未返回允许的响应头，浏览器就会拦截数据并报错，接口在 Postman 中通，不代表在浏览器中也能正常工作,必须确保服务器端配置正确。
*问题 2：我已经在后端设置了 `Access-Control-Allow-Origin: ，为什么携带 Cookie 的请求还是失败了？** **解答：** 这是一个非常常见的陷阱，当你的前端请求设置了withCredentials: true（在fetch或axios中），表示请求需要携带凭据（如 Cookies），在这种情况下，服务器的Access-Control-Allow-Origin响应头**不能**使用通配符*，必须明确指定一个具体的源，例如Access-Control-Allow-Origin: https://your-frontend.com，服务器还必须设置Access-Control-Allow-Credentials: true`，这是 CORS 规范的强制要求,目的是为了防止凭据信息泄露给任意的恶意网站。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
发表回复