跨域错误是浏览器拦截而非前端代码错误，需先看控制台灰色提示定位问题类型，再用curl验证PHP是否真实返回CORS响应头。
跨域错误不是前端代码写错了，而是浏览器在替你拦下了不合规的请求——先看控制台报错类型，再查 PHP 响应头是否真生效。
看懂浏览器控制台里的 CORS 错误提示
真正要盯住的是 Failed to fetch 或 net::ERR_FAILED 下面那行灰色小字，不是红色堆栈本身：
-
No 'Access-Control-Allow-Origin' header is present on the requested resource→ 后端根本没返回 CORS 头（PHP 没执行或被缓存/中间件拦截） -
The value of the 'Access-Control-Allow-Origin' header must not be the wildcard '*' when the request's credentials mode is 'include'→ 前端用了credentials: 'include'，但 PHP 返回了*，必须改成具体域名 -
Response to preflight request doesn't pass access control check→ OPTIONS 请求失败，PHP 没处理预检（比如没响应OPTIONS方法，或漏了Access-Control-Allow-Headers）
PHP 后端加 CORS 头的正确位置
不能只在某个接口函数里 echo header()，得确保它出现在任何可能被跨域调用的响应之前，且不被后续逻辑覆盖：
- 放在入口文件最顶部（如
index.php开头），或框架的全局中间件中 - 用
header('Access-Control-Allow-Origin: https://your-frontend.com', true)，true参数强制替换已有同名头 - 如果支持凭据，必须同时设
Access-Control-Allow-Credentials: true，且Origin不能为* - 预检需要额外加
Access-Control-Allow-Methods: GET, POST, OPTIONS和Access-Control-Allow-Headers: Content-Type, X-Requested-With
为什么加了 header 还是没生效？常见干扰点
PHP 的 header() 只对 HTTP 响应起作用，很多地方会悄悄把它废掉：
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
立即学习“PHP免费学习笔记（深入）”；
- 输出了空格、BOM、echo 语句或 var_dump 在 header() 之前 → 浏览器收不到头，只当普通 HTML 响应
- Nginx/Apache 配置里有
add_header覆盖了 PHP 的设置（尤其注意 Nginx 的add_header默认不继承，需加always） - PHP-FPM 缓存了响应头（少见但存在），可临时加
header_remove()清理再设 - 某些 CMS 或框架（如 Laravel 的 CORS 中间件）已内置处理，重复加会导致冲突
用 curl 快速验证 PHP 是否真返回了 CORS 头
绕过浏览器，直接看原始响应头：
curl -I -H "Origin: https://your-frontend.com" https://your-api.com/api/data
重点检查输出里是否有：
Access-Control-Allow-Origin: https://your-frontend.com-
Access-Control-Allow-Credentials: true（如果前端带 cookie） -
Access-Control-Allow-Methods和Access-Control-Allow-Headers（如果有自定义 header 或非 GET/POST）
如果 curl 能看到头，但浏览器看不到，基本就是前端发请求时没带 Origin（比如本地 file:// 协议），或者被浏览器扩展（如 CORS 插件）干扰了。这类问题容易卡在“明明后端对了却还是报错”的环节，得一层层排除。
