PHP 本身并不会拦住跨域请求，真正执行拦截的是浏览器。 很多时候之所以会失效，问题就出在 credentials: 'include' 和 Access-Control-Allow-Origin: * 同时存在。这种写法是行不通的。

正确做法是把 Access-Control-Allow-Origin 明确写成具体域名，并同时设置 Access-Control-Allow-Credentials: true。另外还有一个很容易被忽略的细节：header() 必须在任何输出内容之前执行。

很多人一看到这类报错，就会下意识觉得是 PHP 把 JS 的跨域请求拦下来了。其实并不是这么回事。

像 Access to fetch at 'http://api.example.com' from origin 'http://localhost:3000' has been blocked by CORS policy 这种错误，本质上是浏览器在拿到响应之后，依据 CORS 规则主动把数据丢弃了，并不是 PHP 端直接拒绝了这次请求。

跨域限制到底是谁在拦

核心点在于：拦截动作来自浏览器，不是 PHP。 PHP 只是返回响应，浏览器再根据 CORS 规则决定是否放行。

所以，看到跨域报错时，排查重点不该只放在 PHP 是否“拒绝请求”，而要先看响应头是否符合浏览器要求。

为什么 header("Access-Control-Allow-Origin: *") 有时不起作用

最常见原因是：前端用了 credentials: 'include'，比如带 Cookie 或 Authorization 头，而 PHP 却写了 Access-Control-Allow-Origin: *。这两者不能共存，浏览器会直接拒绝响应。

• 如果前端需要传 Cookie 或认证头，PHP 必须写具体域名：header("Access-Control-Allow-Origin: http://localhost:3000");
• Access-Control-Allow-Credentials: true 必须显式设置，且只能配合具体域名使用
• 确保该 header() 调用在任何输出（包括空格、BOM、echo、print）之前执行，否则报 headers already sent

OPTIONS 预检请求返回 405 或空白怎么办

非简单请求会触发浏览器先发一个 OPTIONS 请求，比如 PUT、带 Authorization 头的 POST。

如果 PHP 没处理它，Apache/Nginx 可能直接返回 405（Method Not Allowed）或 404。

• 必须在业务逻辑前加判断：if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') { http_response_code(200); exit; }
• Apache 的 .htaccess 或 Nginx 配置可能重写了 OPTIONS，需确认 rewrite 规则没吞掉它
• 某些 FastCGI 模式下，$_SERVER['REQUEST_METHOD'] 在预检时可能不可靠，可改用 getenv('REQUEST_METHOD') 做兜底

header() 写在哪？多个 PHP 文件怎么统一管

不能只在某个 API 文件里加，得覆盖所有被前端调用的入口点。逐个修改容易漏，也不利于维护。

• 推荐方式：在公共入口（如 index.php 或框架的中间件）统一注入 CORS 头
• Apache 下可用 .htaccess：Header set Access-Control-Allow-Origin "https://your-frontend.com"（需启用 mod_headers）
• Nginx 下在 location 块里加：add_header 'Access-Control-Allow-Origin' 'https://your-frontend.com';
• 注意：Nginx 的 add_header 不继承父级，子 location 需重复写或用 include 抽离

排查跨域问题时要看什么

真正麻烦的不是加几行 header()，而是前端请求方式决定了后端要怎么配。

• 前端发什么请求
• 带不带凭证
• 使用什么方法
• 是否会触发 OPTIONS 预检
• 是否可以使用通配符

这些因素会直接决定 PHP 要配哪几个头、要不要处理 OPTIONS、能不能用通配符。

漏掉任意一环，浏览器就会静默失败。 有时候甚至连 network 面板里都看不出后端有没有响应成功。

《夸克》非常好用的免费AI浏览器

下载APP查看