php跨域失败主因是header()调用位置错误、未配全必要头字段、未处理options预检；必须确保header在任何输出前执行，带cookie时需动态校验origin并配全access-control-allow-origin、credentials与headers三头，且入口处拦截options请求返回对应响应头。
PHP跨域问题不是“加个 header 就完事”，而是“加在哪儿、加什么、加几次”共同决定的——90% 的失败都卡在这三点上。
header('Access-Control-Allow-Origin') 为什么总不生效
最常见原因：输出提前。哪怕 header() 前有一行空行、一个 UTF-8 BOM 字节、或 require 的某个配置文件里有 echo，都会触发 Cannot modify header information 警告，且响应头彻底丢失。
- 用 VS Code 或 Notepad++ 检查 PHP 文件是否为「无 BOM 的 UTF-8」编码
- 确认
header("Access-Control-Allow-Origin: *")出现在 任何输出之前，包括print、var_dump、HTML 标签、甚至空白符 - 如果用了框架（如 Laravel、ThinkPHP），别在控制器方法里硬写
header()；优先走中间件或响应对象的withHeader()方法 - 用
curl -I http://your-api.com/endpoint直连验证，比浏览器 Network 面板更可靠（它不会缓存旧响应）
带 Cookie 或 Authorization 时怎么配 Origin
Access-Control-Allow-Origin: * 和 Access-Control-Allow-Credentials: true 是互斥的——浏览器强制拒绝两者共存。必须动态校验并回传匹配的源。
- 读取请求头：
$origin = $_SERVER['HTTP_ORIGIN'] ?? ''; - 白名单校验（不能用逗号分隔字符串，浏览器不认）：
in_array($origin, ['https://app.example.com', 'https://admin.example.net']) - 只对匹配的源输出：
header("Access-Control-Allow-Origin: $origin"); - 必须同时设置：
header("Access-Control-Allow-Credentials: true");和header("Access-Control-Allow-Headers: Content-Type, Authorization"); - 前端 fetch 必须显式声明：
credentials: 'include'，否则浏览器根本不会发 Cookie
OPTIONS 预检请求返回 405 或直接挂掉
浏览器对 POST 带 Content-Type: application/json、或含自定义头的请求，会先发 OPTIONS 探路。如果后端没接住，Web 服务器（Apache/Nginx）就直接返回 405，PHP 根本没机会执行。
- 在入口脚本（如
index.php）最开头加判断：if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') { header("Access-Control-Allow-Origin: *"); header("Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS"); header("Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With"); exit(0); } - Apache 下确保
mod_headers已启用，否则.htaccess里的Header指令无效 - Nginx 需在
location ~ \.php$前加if ($request_method = OPTIONS) { ... }规则，仅靠add_header不够 - 预检响应至少要带
Access-Control-Allow-Methods和Access-Control-Allow-Headers，缺一不可
用 .htaccess 还是 PHP 脚本设 CORS 头
两者适用场景不同：.htaccess 更稳定，绕过 PHP 输出逻辑；但无法处理动态 Origin 校验，也拦不住 OPTIONS 请求（除非配合 RewriteRule）。
- 开发环境快速验证：直接在 PHP 文件开头加
header()最快 - 多接口共用同一策略、且无需动态 Origin：用
.htaccess更干净，避免 headers already sent 风险 - 生产环境需校验白名单或支持凭证：必须用 PHP 层逻辑，
.htaccess无法做条件判断 - 反向代理（如 Nginx → PHP-FPM）时，注意
Origin是否被透传；Nginx 默认不转发Origin，需加proxy_set_header Origin $http_origin;
真正难的不是写那几行 header()，而是搞清请求路径上每个环节（浏览器 → CDN → 反向代理 → PHP）是否都放行、是否都透传、是否都按规范响应——漏掉任意一环，CORS 就会静默失败，连错误信息都不给你看。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
