PHP加Access-Control-Allow-Origin需确保header()在任何输出前调用，禁用BOM，框架中用响应对象设置；带凭证时不能用*而须指定域名；预检请求需配Methods、Headers及OPTIONS处理；Web服务器可能覆盖头，应统一由PHP控制或配置always；Safari/iOS需Vary: Origin和避免缓存。
PHP 后端怎么加 Access-Control-Allow-Origin 才生效
加了 header('Access-Control-Allow-Origin: *') 却还是报跨域错误，大概率是响应头没在真正输出前设置，或者被其他逻辑覆盖。PHP 的 header 必须在任何实际输出（包括空格、BOM、echo、var_dump）之前调用。
- 检查文件开头有没有 UTF-8 BOM —— 用编辑器（如 VS Code）切换到“显示不可见字符”，确认没有隐藏字节
- 确保
header()在session_start()、ob_start()或任何echo/print之前执行 - 如果用了框架（如 Laravel、ThinkPHP），别直接在控制器里写
header()，优先走框架的响应构造机制（比如 Laravel 的response()->header()） - 若需允许带凭证（
withCredentials: true），Access-Control-Allow-Origin不能为*，必须指定具体域名，例如https://example.com
为什么只设 Origin 不够？还要配 Access-Control-Allow-Methods 和 Access-Control-Allow-Headers
浏览器预检请求（preflight，比如含 Content-Type: application/json 或自定义 header 的 POST）会先发一个 OPTIONS 请求。后端不响应对应 header，预检就失败，真实请求根本不会发出。
- 常见漏配项：
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS—— 方法列表要和前端实际发的一致 -
Access-Control-Allow-Headers必须包含前端请求中出现的所有自定义头，比如Authorization、X-Requested-With、Content-Type（即使它是标准头，也得显式声明） - 记得对
OPTIONS请求单独处理：如果是纯手工 PHP，建议在入口处拦截$_SERVER['REQUEST_METHOD'] === 'OPTIONS'并直接exit，避免走到业务逻辑
本地开发时 Nginx / Apache 反代下，PHP 的 header 会被覆盖吗
会。Web 服务器可能重写或忽略 PHP 输出的 CORS header，尤其当配置了 add_header（Nginx）或 Header set（Apache）且未启用 always 修饰符时。
- Nginx 中，用
add_header ... always;确保响应头在所有状态码下都生效（否则 404、500 时不发送） - Apache 中，用
Header always set ...替代Header set - 更稳妥的做法：关掉 Web 服务器层的 CORS 配置，只由 PHP 控制，避免多层 header 冲突
- 验证方式：用
curl -I http://your-api/xxx查看实际返回的 header，别只信浏览器 Network 面板（它可能缓存预检结果）
PHP 设置 CORS 后，为什么 Safari 或 iOS WebView 仍报错
Safari 对 Access-Control-Allow-Origin 和 Vary 头更敏感。如果后端动态返回不同 Origin（比如根据 $_SERVER['HTTP_ORIGIN'] 白名单判断），但没同步设置 Vary: Origin，Safari 可能缓存错误的响应并复用。
立即学习“PHP免费学习笔记（深入）”；
- 动态允许 Origin 时，必须加
header('Vary: Origin'); - 确保
Access-Control-Allow-Credentials: true和Access-Control-Allow-Origin域名匹配，且不能是* - iOS 15+ 对预检缓存时间更短，频繁改 header 容易触发旧缓存，可临时加
Cache-Control: no-store排查 - 真机调试时，用 macOS 的 Console.app 抓取 WebKit 日志，比 Chrome DevTools 显示更多底层拒绝原因
