PHP实时输出失效时，需先确认ob_flush()和flush()是否成对调用；若启用zlib压缩须关闭；Nginx需配置fastcgi_buffering off；可用ob_implicit_flush(true)简化，但需配合ob_start()；验证应使用Chrome DevTools Network的Stream response功能。
PHP 实时输出失效时，先确认 ob_flush() 和 flush() 是否成对调用
PHP 默认启用输出缓冲（output buffering），echo 或 print 的内容不会立刻发给浏览器，而是等脚本结束或缓冲区满才送出。要实现“实时”，必须手动干预缓冲链：先清空 PHP 的输出缓冲（ob_flush()），再清空 Web 服务器/响应层的缓冲（flush()）。漏掉任意一个，都看不到逐行输出效果。
常见错误现象：echo "a"; sleep(1); echo "b"; 两秒后一次性看到 “ab”；或者只看到第一行，后续卡住。
- 必须在
echo后立即调用ob_flush()和flush() - 若启用了
zlib.output_compression（常见于 shared hosting），它会拦截并压缩整个响应，导致flush()失效 —— 需在脚本开头加ini_set('zlib.output_compression', 'Off'); - 某些 SAPI（如 PHP-FPM + Nginx）默认禁用
fastcgi_buffering off，需在 Nginx 配置中显式关闭，否则flush()被 Nginx 缓存截断
用 ob_implicit_flush(true) 简化重复调用
避免每行都写 ob_flush() + flush()，可在脚本开头启用隐式刷新模式：ob_implicit_flush(true)。它会让每次 echo/print 后自动触发 ob_flush() 和 flush()，但前提是输出缓冲已启动（即 ob_start() 已调用，或默认缓冲开启）。
注意：ob_implicit_flush() 不影响底层 SAPI 缓冲（如 Apache 的 mod_deflate、Nginx 的 fastcgi_buffering），它只管 PHP 层。所以仍需检查服务器配置是否允许逐块传输。
立即学习“PHP免费学习笔记（深入）”；
- 推荐搭配
ob_start()显式开启缓冲，再设ob_implicit_flush(true)，避免依赖默认行为 - 若使用
ob_end_clean()或ob_end_flush()提前结束缓冲，隐式刷新会失效 - CLI 模式下该函数无效（无 HTTP 输出流），仅适用于 Web SAPI
Chrome DevTools Network 标签页是验证实时输出最可靠的工具
不要依赖浏览器页面渲染节奏判断是否“实时”—— 页面可能因 HTML 解析、CSS 渲染延迟而滞后。真正要看的是响应体（Response）是否分块到达。打开 Chrome DevTools → Network → 点击请求 → 查看 Response 标签页，勾选 “Stream response”（Chrome 90+ 默认开启），就能看到数据随时间逐段追加。
常见误判场景：页面显示空白几秒后突然刷出全部内容，但 Network 中 Response 已分段接收 —— 这说明是前端渲染问题（如 JS 阻塞、DOM 更新未及时），而非 PHP 输出失败。
- 确保请求是普通 GET，非 XHR/Fetch（某些 Fetch API 默认等待 complete，需设置
responseType: 'text'并监听response.body.getReader()） - 禁用浏览器缓存（DevTools → Network → Disable cache），防止旧响应被复用
- 响应头中若含
Content-Encoding: gzip，说明压缩未关闭，flush()必然失败
调试时加 usleep(10000) 避免输出过快淹没观察窗口
单纯 echo + flush() 可能因执行太快，在 Network 或终端里看不出“实时感”。人为插入微小延迟（如 usleep(10000) 即 0.01 秒），能让分块更易识别，也方便定位哪一行卡住。
示例片段：
这个循环会在 Network 中清晰显示 5 次独立的数据块抵达（前提是服务端配置允许）。如果某次没出现，说明从那一行开始缓冲被意外关闭、或服务器层拦截了。
真正复杂的地方不在 PHP 代码本身，而在于你无法一眼看出 Nginx/Apache/PHP-FPM 三层缓冲中哪一层在吃掉你的 flush() —— 每个环境都要单独验证。