根本原因是浏览器基于X-Frame-Options和Content-Security-Policy的frame-ancestors策略拒绝跨域嵌入，而非CORS；服务端必须同时设置这两个响应头，且frame-ancestors不支持通配符或逗号分隔。
PHP 输出内容到跨域 iframe 时浏览器直接拦截，根本原因是什么
不是 PHP 没输出，而是浏览器在加载 <iframe src="https://other-domain.com/xxx.php"> 时，一旦目标页没显式声明 Access-Control-Allow-Origin 或未满足 iframe 嵌入策略，就直接拒绝渲染——哪怕 PHP 已经成功执行并返回了 HTML。关键点在于：iframe 跨域嵌入本身不触发 CORS 检查，但受 X-Frame-Options 和 Content-Security-Policy 的 frame-ancestors 控制；而 iframe 内 JS 尝试访问父页面或反之，则会触发跨域限制。
服务端必须加的两个响应头（缺一不可）
如果目标 PHP 文件（即 iframe 的 src）需要被其他域名嵌入，且你控制该服务端，必须在 PHP 中输出前设置：
-
header('X-Frame-Options: ALLOW-FROM https://your-main-site.com');（旧标准，部分浏览器已弃用） -
header("Content-Security-Policy: frame-ancestors https://your-main-site.com;");（推荐，现代浏览器强制要求）
注意：frame-ancestors 不支持通配符 * 配合 https 协议（即 https://* 无效），也不允许写多个域名用逗号分隔，只能空格分隔多个明确域名；若需兼容多来源，得动态判断 $_SERVER['HTTP_ORIGIN'] 或 $_SERVER['HTTP_REFERER'] 后拼接（但后者可伪造，仅作简单过滤）。
PHP 实时输出（flush）在 iframe 里失效的常见陷阱
即使跨域策略放行，echo + flush() + ob_flush() 在 iframe 中也常“卡住不动”，原因包括：
立即学习“PHP免费学习笔记（深入）”；
- Web 服务器（如 Nginx）默认启用
proxy_buffering on，会缓存整个响应体才发给浏览器；需在 location 块中加proxy_buffering off; - PHP 的
output_buffering开启（php.ini 中非0或Off）会拦截所有flush()；检查ini_get('output_buffering')，必要时开头加@ini_set('output_buffering', 'Off');（注意：CLI 下无效，且某些 SAPI 如 FPM 可能不完全支持） - 浏览器对 iframe 的流式解析不友好——它往往等待
</html>或超时后才开始渲染，所以务必在输出中穿插<script>parent.updateLog?.(data)</script>类主动通信，而非依赖 DOM 自动刷新
替代方案：不用 iframe，改用 postMessage + fetch 更可控
如果只是想让主站实时获取子域/跨域 PHP 脚本的执行日志或进度，比 iframe 更可靠的做法是：
- PHP 后端提供一个纯数据接口（如
/api/progress.php?task_id=abc），返回 JSON 流或轮询结果 - 主站前端用
fetch()或EventSource（仅同源或 CORS 显式允许）拉取 - 若必须跨域且要双向通信，用
window.postMessage()：iframe 加载后，父页监听message，iframe 内 PHP 渲染的 JS 主动调用parent.postMessage({type:'log', data:'xxx'}, 'https://your-main-site.com')
这种方式绕开了 iframe 渲染生命周期和流式输出的不确定性，也避免了 header 设置遗漏导致的白屏问题。
真正麻烦的从来不是 PHP 怎么 echo，而是浏览器怎么信你、服务器怎么放行、前端怎么接住那条“还没结束”的数据流——每个环节断掉，用户看到的都只是空白 iframe。
