文章目录▼CloseOpen

• 最常用的CORS配置：别光加Origin，这些细节才是坑
• JSONP：别只记“回调函数”，这些雷区要避开
• 反向代理：让前端不用管跨域，后端悄悄解决
• CORS配置里用了，为什么带cookie还是跨域？
• JSONP为什么不能发POST请求？
• Nginx反向代理时，proxy_pass后面的斜线要不要加？
• 多个前端域名要允许跨域，CORS怎么配置？
• OPTIONS请求是什么？为什么要处理它？

别慌，这篇文章把PHP解决跨域的实用方法讲得明明白白——从最常用的CORS响应头配置（具体加哪些字段、怎么避免“配置了还跨域”的坑），到JSONP的正确用法（避开“不支持POST请求”的雷区），再到反向代理的落地技巧，每一种方法都附亲测有效的代码示例。连新手容易忽略的“携带Credentials时的头配置”“多域名白名单怎么写”这些细节，也帮你标好了避坑要点。

不管你是刚接触跨域的新手，还是踩过坑的老鸟，跟着走一遍，分分钟搞定跨域报错，再也不用为这种“小问题”耗时间！

做PHP开发的你，是不是跟我一样，碰到过这种事儿？前端刚写完接口调用，一点击就弹“Access-Control-Allow-Origin”错误，控制台红得刺眼，明明接口在Postman里测是好的，到前端就卡壳。上次我帮做生鲜电商的朋友调API，他就卡在这一步，急得直挠头——用户等着看商品列表呢，结果跨域把整个流程堵死了。别慌，我把自己踩过的坑、亲测有效的解决办法整理了一遍，今天一次性说清楚，你跟着做，大概率能避开90%的跨域雷区。

最常用的CORS配置：别光加Origin，这些细节才是坑

其实跨域问题的核心，就是浏览器的“同源策略”——它不让不同域名、端口、协议的请求随便交互。而CORS（跨源资源共享）就是浏览器给的“通行证”，让后端通过响应头告诉浏览器“这个前端可以访问我”。我平时写PHP接口，一定会在入口文件里加这几行代码：

// 允许的前端域名（别用，除非你不想带cookie）
header('Access-Control-Allow-Origin: https://your-frontend.com');
// 允许的请求方法（GET/POST这些常用的都加上）
header('Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS');
// 允许的请求头（比如Content-Type、Authorization）
header('Access-Control-Allow-Headers: Content-Type, Authorization');
// 允许携带cookie（要是前端要传sessionid，这行必须加）
header('Access-Control-Allow-Credentials: true');

你别觉得这几行简单，我朋友之前就栽在“Credentials”上——他一开始用了Access-Control-Allow-Origin: ，结果前端带cookie的时候还是报错。后来我告诉他，当Credentials设为true时，Origin不能用通配符，必须写具体的前端域名，改完之后立马好了。

还有个容易忽略的点：OPTIONS请求。浏览器发POST、PUT这类“非简单请求”时，会先发一个OPTIONS请求“探路”，问后端“我能发这个请求吗？”。要是你没处理这个请求，浏览器会直接判定跨域。我一般会在PHP里加个判断：

if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') {
 // 直接返回204状态码，别输出任何内容
 http_response_code(204);
 exit;
}

去年帮做教育APP的朋友调接口，他就是没处理OPTIONS请求，导致前端发POST的时候一直报错，改了这行代码才解决。对了，要是你有多个前端域名要允许（比如h5和小程序），可以用数组存白名单，动态判断Origin：

$allowedOrigins = ['https://h5.your-app.com', 'https://mp.your-app.com'];
$origin = $_SERVER['HTTP_ORIGIN'] ?? '';
if (in_array($origin, $allowedOrigins)) {
 header("Access-Control-Allow-Origin: $origin");
}

这样既灵活又安全，比写死一个域名好用多了——毕竟谁也不想改一次前端域名，就去后端改一次代码对吧？

JSONP：别只记“回调函数”，这些雷区要避开

要是你碰到需要兼容IE8、IE9的老项目，CORS可能不好使（这些浏览器不支持），那JSONP就是你的“救命稻草”。它的原理特别简单：用标签加载跨域资源——因为浏览器允许script标签请求不同域名的文件。

比如前端要拿商品列表，会写个回调函数：

function handleProducts(data) {
 console.log('拿到商品数据了：', data);
}
// 创建script标签，请求PHP接口
var script = document.createElement('script');
script.src = 'https://your-api.com/products.php?callback=handleProducts';
document.body.appendChild(script);

PHP接口里要做的，就是把数据用回调函数包起来返回：

$callback = $_GET['callback'] ?? '';
// 要返回的数据
$products = [
 ['id' => 1, 'name' => '苹果', 'price' => 10],
 ['id' => 2, 'name' => '香蕉', 'price' => 5]
];
// 输出“handleProducts(...)”这样的格式
echo $callback . '(' . json_encode($products) . ')';

但JSONP有两个绝对不能踩的坑：第一，它只支持GET请求——我之前帮朋友调的时候，他非要用POST传大量数据，结果折腾了半天没用，最后改成GET加参数才解决；第二，要过滤回调函数名，避免XSS攻击——比如有人传callback=alert('攻击')，要是你直接输出，前端就会执行恶意代码。我一般会用正则检查：

if (!preg_match('/^[a-zA-Z0-9_]+$/', $callback)) {
 http_response_code(400);
 echo '无效的回调函数名';
 exit;
}

JSONP是“老时代的产物”，要是你不用兼容老浏览器，尽量别用——毕竟安全和灵活性都不如CORS。

反向代理：让前端不用管跨域，后端悄悄解决

要是你嫌CORS配置麻烦，或者前端是Vue、React这类单页应用，那反向代理绝对是“懒人福音”。简单说就是用服务器（比如Nginx）把前端的请求“转发”到PHP后端，这样前端请求的是同一个域名，自然不会跨域。我去年帮做招聘平台的朋友部署项目，他们前端是Vue，后端是PHP，用Nginx反向代理后，前端完全不用改代码，省了好多事。

具体怎么配置呢？比如你的前端部署在https://your-website.com，后端API在https://your-api.com，Nginx的配置可以这么写：

server {
 listen 443 ssl;
 server_name your-website.com;
 # 处理前端静态文件（比如Vue的dist目录）
 location / {
 root /path/to/frontend/dist;
 index index.html;
 try_files $uri $uri/ /index.html; # 解决Vue路由刷新404的问题
 }
 # 反向代理到PHP后端
 location /api/ {
 proxy_pass https://your-api.com/; # 注意后面的斜线！不然路径会错
 proxy_set_header Host $proxy_host; # 把真实的后端域名传给PHP
 proxy_set_header X-Real-IP $remote_addr; # 传递客户端真实IP
 }
}

这里有个关键细节：proxy_pass后面的斜线必须加——要是你写成https://your-api.com（没斜线），那前端请求/api/products会被转发到https://your-api.com/api/products；加了斜线，就会转发到https://your-api.com/products，正好对应后端的接口路径。我之前帮朋友调的时候，就因为没加斜线，导致后端收到的路径多了个/api，结果接口找不到，折腾了半小时才发现问题。

要是你用Apache服务器，也可以用mod_proxy模块做反向代理，在.htaccess里加这么几行：

RewriteEngine On
把/api开头的请求转发到后端
RewriteRule ^api/(.)$ https://your-api.com/$1 [P,L]

不管用Nginx还是Apache，反向代理的核心都是“让前端和后端看起来是同一个域名”——这样浏览器就不会触发同源策略，跨域问题自然解决。

我把这三种方法的优缺点、适用场景整理成了表格，你一眼就能看清：

你要是拿不定主意，按这个表格选就行——比如做电商API，优先选CORS；做企业官网兼容老浏览器，选JSONP；做Vue项目部署，选反向代理。

我之前帮好几个朋友解决跨域问题，都是用这些方法，基本上没翻车。你要是按我说的试了，不管成没成，都可以回来留个言——成了的话让我沾沾喜，没成的话我帮你看看哪儿出问题了。对了，要是你还有别的跨域小技巧，也欢迎分享，咱们互相踩坑互相避坑～

CORS配置里用了，为什么带cookie还是跨域？

这是因为当你设置Access-Control-Allow-Credentials: true（允许携带cookie）时，Access-Control-Allow-Origin不能用通配符，必须写具体的前端域名。浏览器的同源策略要求，带凭证的跨域请求必须明确指定允许的Origin，否则会判定为不安全操作，直接拦截请求。我朋友之前就栽过这个坑，后来把改成前端真实域名，问题立马解决了。

JSONP为什么不能发POST请求？

JSONP的原理是通过动态创建script标签来加载跨域资源，而script标签只能发起GET请求——它本质是“加载脚本”，不是“提交数据”。所以要是你需要发POST请求（比如传大量表单数据），JSONP就不好使了，得换CORS或者反向代理这类支持POST的方法。我之前帮朋友调接口时，他非要用JSONP发POST，折腾了半天没成，最后改成CORS才解决。

Nginx反向代理时，proxy_pass后面的斜线要不要加？

必须加！要是你不加斜线，比如写成proxy_pass https://your-api.com，那前端请求/api/products会被转发到https://your-api.com/api/products（多了个/api路径）；加了斜线写成proxy_pass https://your-api.com/，才会正确转发到https://your-api.com/products。我去年帮招聘平台的朋友部署项目时，就因为没加斜线，导致后端接口找不到，折腾了半小时才发现这个细节。

多个前端域名要允许跨域，CORS怎么配置？

可以用“白名单数组+动态判断”的方法。比如先定义一个允许的域名数组：$allowedOrigins = [‘https://h5.your-app.com’, ‘https://mp.your-app.com’]，然后获取客户端的Origin（$_SERVER[‘HTTP_ORIGIN’]），检查它是否在数组里。如果在，就设置Access-Control-Allow-Origin为这个具体域名；不在的话可以返回403或者忽略。这样既灵活又安全，不用每次加新域名都改代码。

OPTIONS请求是什么？为什么要处理它？

OPTIONS是浏览器发的“预检请求”——当你发POST、PUT这类“非简单请求”时，浏览器会先问后端：“我要发这个请求了，你允许吗？”要是后端没处理OPTIONS请求，浏览器会直接判定跨域。所以PHP里要加个判断：如果$_SERVER[‘REQUEST_METHOD’] === ‘OPTIONS’，就返回204状态码并退出，别输出任何内容。我帮教育APP的朋友调接口时，就是因为没处理OPTIONS，导致POST请求一直报错，改了之后立马好了。