在Web开发中，JavaScript跨域通信是指运行在一个源（协议、域名、端口三者一致）下的脚本，尝试与另一个源的资源或页面进行数据交换的行为。由于浏览器出于安全考虑实施了同源策略，默认的XMLHttpRequest、Fetch以及DOM访问都会被拦截。要实现合法的跨域，必须根据通信对象选择对应机制。
一、CORS：服务端协作的标准跨域方案
CORS（Cross-Origin Resource Sharing）是目前最规范、使用最广的跨域请求方案。它的核心逻辑是：当浏览器发现前端发起的是跨域请求时，会自动在HTTP头中带上Origin字段；服务器若允许该源访问，就在响应头中返回Access-Control-Allow-Origin等字段，浏览器校验通过后才把响应交给脚本。
对于简单请求（如GET、POST且Content-Type为表单类型），浏览器直接发出并在响应中检查CORS头。对于复杂请求（如带自定义头或使用PUT方法），浏览器会先发送一个OPTIONS预检请求，确认服务器许可后才发送真实请求。下面是一段Node.js Express设置CORS头的示例：
const express = require('express');
const app = express();
// 允许来自 http://localhost:3000 的跨域请求
app.use((req, res, next) => {
res.setHeader('Access-Control-Allow-Origin', 'http://localhost:3000');
res.setHeader('Access-Control-Allow-Methods', 'GET,POST,PUT,DELETE,OPTIONS');
res.setHeader('Access-Control-Allow-Headers', 'Content-Type,Authorization');
res.setHeader('Access-Control-Allow-Credentials', 'true');
if (req.method === 'OPTIONS') {
return res.sendStatus(204);
}
next();
});
app.get('/api/data', (req, res) => {
res.json({ message: '这是跨域返回的数据' });
});
app.listen(8080);
使用CORS的优点是透明、安全且支持各种HTTP方法，前端代码无需特殊改造。缺点在于必须控制服务端，若调用的是无CORS支持的第三方接口则无法直接采用。此外，配置Access-Control-Allow-Credentials为true时，Allow-Origin不能为通配符星号，否则浏览器会拒绝携带凭证。
二、postMessage：窗口间跨域通信机制
当通信双方是不同源的页面（例如父页面嵌入了其他域的iframe，或通过window.open打开了异地窗口），就需要使用HTML5提供的window.postMessage API。它允许一个窗口向另一个窗口发送字符串或可被结构化克隆的对象，并携带来源标识，接收方通过message事件监听。
发送方调用targetWindow.postMessage(data, targetOrigin)指定目标源，接收方在事件中校验event.origin防止伪造。以下代码演示了父页面向iframe子页面发送指令并接收回复：
// 父页面代码
const iframe = document.getElementById('myFrame');
iframe.contentWindow.postMessage('请发送用户ID', 'https://child.ipipp.com');
window.addEventListener('message', (event) => {
// 严格校验来源
if (event.origin !== 'https://child.ipipp.com') return;
console.log('收到子页面消息:', event.data);
});
// 子页面代码
window.addEventListener('message', (event) => {
if (event.origin !== 'https://parent.ipipp.com') return;
if (event.data === '请发送用户ID') {
event.source.postMessage({ userId: 1001 }, event.origin);
}
});
postMessage不依赖服务端配合，适合微前端、跨域弹窗、嵌入组件等场景。但要注意，targetOrigin不能偷懒写成星号，否则可能把敏感数据发往任意恶意页面；接收端也必须校验event.origin与event.source，否则容易被伪造消息攻击。
三、JSONP：历史遗留的脚本注入式方案
在CORS普及之前，开发者利用<script>标签不受同源限制的特性实现跨域数据获取，这就是JSONP。其原理是前端动态创建script标签，src指向跨域接口并附带回调参数名；服务端返回一段调用该回调函数的JS代码，将数据包在参数里。
由于仅依靠脚本加载，JSONP只能处理GET请求，且接口返回内容直接执行，若服务端被劫持会带来XSS风险。示例代码如下：
function handleData(resp) {
console.log('JSONP获取数据:', resp);
}
const script = document.createElement('script');
script.src = 'https://api.ipipp.com/data?callback=handleData';
document.body.appendChild(script);
服务端（以PHP为例）会输出：
<?php
$callback = $_GET['callback'];
$data = json_encode(['name' => 'test']);
echo $callback . '(' . $data . ');';
?>
JSONP如今已逐渐淘汰，仅用于兼容极老系统或某些不支持CORS的公开接口。新项目应优先使用CORS或postMessage，以保证安全性与可维护性。
四、其他辅助与替代方式
除了上述三种主流方式，还有基于代理中转的思路：同源前端请求自己的后端，由后端服务器以HTTP客户端身份访问跨域资源，从而绕过浏览器限制。这种方式对前端完全透明，常用于聚合多个第三方API。另外，WebSocket连接不受同源策略约束，只要服务端允许即可跨域全双工通信。
在选择方案时，可参考下表快速判断：
| 场景 | 推荐方案 | 是否需服务端改 |
|---|---|---|
| 前端调异地REST接口 | CORS | 是 |
| 父页与跨域iframe通信 | postMessage | 否 |
| 老系统GET跨域 | JSONP | 是（返回JS） |
| 不愿暴露第三方域名 | 后端代理 | 是（己方后端） |
理解这些机制的差别，才能在实际架构中平衡开发效率与安全合规，避免盲目使用星号放行或忽略来源校验带来的隐患。
JavaScriptcross_origin_communicationCORS修改时间：2026-08-10 05:24:32