跨域问题是前端与后端协作中不可避免的话题，处理不当将直接影响系统可用性与安全性。本文将系统梳理跨域的概念、原理、常见解决方案，并结合实际开发中易错点进行总结，帮助你全面掌握跨域知识。

一、什么是跨域？

**跨域（Cross-Origin）**是指浏览器出于安全策略限制，当前网页试图访问另一个域名下的资源时受到的限制。

1.1 同源策略（Same-Origin Policy）

同源策略是浏览器的安全基石。只有当协议、域名、端口三者完全一致时，才视为同源（三者中任意一个不同即为跨域）。否则，即为跨域。

示例：

1.2 浏览器的跨域限制范围

要理解跨域问题，必须搞清楚浏览器到底在哪些场景下会进行“同源策略检查”，也就是说，浏览器的跨域限制到底限制了什么？哪些行为会被拦截，哪些行为不会？

1.2.1 浏览器的同源策略主要对以下几个方面进行“同源限制”：

1. DOM 访问限制（最严格）

这是最基本的限制类型，也是最容易被忽视的一类。

举个例子：

<!-- 主页面 -->
<iframe src="https://other.com/page.html"></iframe>

<script>
  const frame = document.querySelector('iframe');
  console.log(frame.contentWindow.document); //  报错：Permission denied
</script>

说明：

• 不同源的 iframe 页面之间不能互相访问 DOM 或 JS 对象。
• 这是为了防止你在 a.com 上加载 b.com 页面后篡改其内容或读取其表单数据。

2. Cookie / LocalStorage / SessionStorage 限制

跨域脚本不能读取或操作其他源的存储内容。

比如：

// 当前页面是 https://a.com
console.log(document.cookie); // 只能访问 a.com 的 cookie
console.log(localStorage.getItem('token')); // 只能访问 a.com 的存储空间

即便你能通过 <script src="https://b.com/evil.js"> 加载 b.com 的脚本，它也无法操作 a.com 的本地存储，因为其执行上下文仍然归属 a.com，而不是 b.com。

除非服务端设置了 document.domain 或使用 postMessage 等手段，才能安全地进行通信。

3. AJAX / Fetch 请求限制

这是我们日常遇到跨域问题最多的地方。

如果你用 XMLHttpRequest 或 fetch 去请求不同源的接口，默认会被浏览器拦截响应内容：

// 当前在 https://a.com 页面
fetch('https://b.com/api/user')
  .then(res => res.json())
  .then(data => console.log(data)); //  浏览器阻止读取响应

• 请求虽然已经发出，甚至在服务器已经返回数据。
• 但浏览器不会把响应内容交给 JavaScript，除非目标服务端通过 CORS 明确允许该请求。

4. WebSocket 限制（部分受控）

WebSocket 连接也受同源策略影响，虽然不像 HTTP 那样严格，但大多数浏览器仍会进行协议和源头的校验：

const socket = new WebSocket('wss://b.com/socket');
// 如果服务器没有正确设置跨源允许，也可能连接失败

尤其是在企业内网、认证系统中部署 WebSocket 时，如果浏览器或服务端未正确设置 Origin 校验，也可能会出现连接失败的问题。

5. 跨源资源加载行为（宽松处理）

浏览器在加载一些“静态资源”（如 JS、图片、音视频等）时对跨域是比较宽松的，不会阻止资源加载，但有响应限制：

• <script src="https://cdn.com/lib.js"> 可以跨域加载 JS；
• <img src="https://img.com/a.jpg"> 可以显示外部图片；
• <link rel="stylesheet" href="https://css.com/main.css"> 可以加载外部样式表。

但是：

• 通过 JS 无法获取这些资源的详细内容（如 img 的像素值，canvas 操作会受限制）；
• 某些资源请求在服务端未设置 Access-Control-Allow-Origin 时，响应内容不可读取（如 JS 动态请求字体、视频元信息时）。

浏览器不管的：跨域行为

有一些“跨域行为”其实并不会被浏览器限制，比如：

总结一句话：

浏览器的跨域限制主要是：限制 JS 脚本访问其他源的数据和资源，重点在于“读取”和“操作” ，而不是“发送请求”。

所以开发中跨域问题大多发生在 接口调用（AJAX / fetch）时想读取跨源数据，或者 iframe 想访问跨源页面的 DOM，而并非加载图片、跳转链接这样的行为。

理解这些“限制边界”，才能更有针对性地选择跨域解决方案，比如 CORS、代理、postMessage、JSONP 等。

二、常见跨域解决方案

2.1 CORS（Cross-Origin Resource Sharing）

CORS 是最推荐的跨域方案，由服务端在响应头中增加跨域控制字段。

关键响应头字段：

• Access-Control-Allow-Origin: 指定允许的来源
• Access-Control-Allow-Methods: 允许的方法（GET, POST 等）
• Access-Control-Allow-Headers: 允许的自定义请求头
• Access-Control-Allow-Credentials: 是否允许携带 cookie

简单请求 vs 预检请求：

• 简单请求：GET/POST 且 Content-Type 为 application/x-www-form-urlencoded 等
• 预检请求（OPTIONS）：非简单请求浏览器先发送一次请求询问服务器是否允许

示例：

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

2.2 JSONP（已过时，了解即可）

• 仅支持 GET 请求
• 利用 <script> 标签无跨域限制的特点
• 服务端返回可执行 JS 回调

<script src="http://api.example.com/data?callback=handle"></script>

function handle(data) {
  console.log(data);
}

缺点：

• 仅支持 GET
• 安全性差，容易被 XSS 攻击
• 不支持请求头自定义

2.3 代理转发（开发常用）

通过开发服务器代理请求，规避浏览器限制

• 原理：前端请求的是同源地址，代理服务器转发到跨域服务端

前端配置示例（以 Vite 为例）：

server: {
  proxy: {
    '/api': {
      target: 'https://backend.example.com',
      changeOrigin: true,
      rewrite: path => path.replace(/^/api/, '')
    }
  }
}

2.4 Nginx 反向代理（生产环境推荐方式）

很多人对 Nginx 代理理解不深，认为它和前端代理一样，其实作用更强大。

核心原理：

Nginx 作为中间层代理服务器，将浏览器的同源请求转发给目标跨域服务，浏览器只与 Nginx 通信，因此从浏览器角度看始终是同源。

示例配置：

server {
  listen 80;
  server_name www.myfrontend.com;

  location /api/ {
    proxy_pass https://api.mybackend.com/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

优势：

• 稳定可靠，适用于线上
• 可统一管理多个后端服务
• 能处理 HTTPS、限流、负载均衡等

易错点：

• 忘记设置 proxy_set_header 可能导致后端拿不到真实 IP
• 路径重写配置不当会返回 404

2.5 postMessage + iframe 跨域通信

适用于两个页面嵌套在 iframe 中的跨域场景。

// 父页面向 iframe 发送
iframe.contentWindow.postMessage('hello', 'https://child.com');

// 子页面监听
window.addEventListener('message', (event) => {
  if (event.origin === 'https://parent.com') {
    console.log(event.data);
  }
});

三、常见错误与易忽略问题总结

3.1 忽视预检请求（OPTIONS）导致接口报错

背景：

当你发送一个复杂请求（如 Content-Type 为 application/json，或带有 Authorization 头）时，浏览器会自动先发送一个 OPTIONS 预检请求 来确认服务端是否允许跨域。

易出现的问题：

• 后端没有处理 OPTIONS 请求，导致 405 或 403 错误
• 接口网关（如 nginx、API 网关）拦截了 OPTIONS 请求
• 接口安全机制将预检请求拒之门外

建议：

1. 服务端需显式支持 OPTIONS 方法：

@RequestMapping(method = RequestMethod.OPTIONS)
public ResponseEntity<?> preflight() {
    return ResponseEntity.ok().build();
}

2. Nginx 配置允许 OPTIONS：

if ($request_method = 'OPTIONS') {
    add_header Access-Control-Allow-Origin *;
    ...
    return 200;
}

3. 设置合理的缓存时间减少预检频率：

Access-Control-Max-Age: 86400

3.2 Access-Control-Allow-Origin 不可与 Credentials 同时使用 *

错误示范：

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

正确示范：

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

3.3 请求头设置过多导致被视为复杂请求

前端在请求中添加不必要的 header（如 token、content-type 设置为 application/json）会触发预检。

建议：

• 简单请求尽量保持 header 简洁
• 服务端应支持预检响应

3.4 忽略缓存带来的跨域问题

预检请求可能会被浏览器缓存，如果服务端配置 Access-Control-Max-Age 太小，导致频繁预检，影响性能。

3.5 开发环境跨域代理配置与线上环境不同

开发中常用代理服务器处理跨域，而上线后 CORS 需要服务端支持，若忽视配置差异，可能导致前端上线后大量跨域失败。

四、业界最佳实践建议

五、总结

跨域问题源于浏览器的同源策略，其解决方式关键在于正确理解浏览器行为、前后端协作规范和服务端配置要求。开发中应根据场景灵活选择解决方案，并注意避免常见误区。

熟练掌握跨域原理和处理技巧，不仅能提升前后端协作效率，也能有效规避安全隐患，是每位开发者必须掌握的技能。