ob_flush无反应是因为它仅清空PHP输出缓冲区，不保证数据立即发往浏览器；需同时调用flush，并满足PHP、Web服务器、代理层和浏览器四层缓冲配置要求。
ob_flush 为啥调用了没反应？
因为 ob_flush 只清空 PHP 的输出缓冲区，不保证数据立刻发到浏览器。它依赖底层 Web 服务器（如 Apache、Nginx）和客户端的缓冲策略。常见现象是：代码里反复调用 ob_flush 和 flush，但浏览器仍等到脚本结束才一次性显示全部内容。
必须同时满足几个条件才能看到“实时”效果：
- PHP 输出缓冲已开启（默认开启，但可能被
ini_set('output_buffering', 'off')关掉） - Web 服务器未启用响应体压缩（如 Nginx 的
gzip on会拦截 chunked 输出） - 浏览器未因响应太小或未收到足够字节而延迟渲染（Chrome 常要求首块 ≥ 1024 字节）
- PHP 脚本中必须配对使用
ob_flush()+flush()，缺一不可
ob_flush 和 flush 的分工是什么？
ob_flush 负责把 PHP 用户层缓冲区（output buffer）里的内容“推给” Web 服务器；flush 则尝试把 Web 服务器当前持有的响应数据“推给”客户端。两者是流水线上的两道工序，不能互相替代。
典型错误写法：ob_flush() 单独调用，或只写 flush() 但 PHP 缓冲区还满着（比如没开 ob_start() 或缓冲区未满触发自动 flush）。
立即学习“PHP免费学习笔记（深入）”；
安全起见，建议统一按这个顺序写：
echo "some content";ob_flush();flush();
如果用了 ob_start()，记得开头就调用，否则 ob_flush() 无缓冲可刷。
为什么在 CLI 或某些 SAPI 下 ob_flush 不生效？
CLI 模式下没有 HTTP 响应概念，ob_flush 和 flush 都被忽略。FastCGI（如 PHP-FPM）环境下，还受 fastcgi_buffering（Nginx）或 proxy_buffering（Apache mod_proxy）影响——这些代理层缓冲会吞掉 chunked 响应，导致前端永远收不到中间数据。
调试时可用 curl -v http://your-script.php 查看响应头是否含 Transfer-Encoding: chunked，并观察 Content-Length 是否为缺失或固定值。若存在 Content-Length，说明响应已被全量缓存，实时输出必然失败。
关键配置检查点：
- Nginx：确认
fastcgi_buffering off;（注意不是fastcgi_buffers） - Apache：禁用
mod_deflate，并检查ProxySet keepalive=on buffering=off（如用 mod_proxy_fcgi） - PHP：确认
output_buffering = 0或Off（phpinfo()查看实际值）
一个能跑通的最小实时输出示例
以下代码在支持的环境（如本地 Apache + mod_php）中可逐秒输出数字：
<?php
if (ob_get_level() == 0) ob_start();
for ($i = 1; $i <= 5; $i++) {
echo "$i<br>";
echo str_repeat(' ', 1024); // 填充至 1024 字节，绕过 Chrome 渲染阈值
ob_flush();
flush();
sleep(1);
}
?>
注意：str_repeat(' ', 1024) 不是装饰，是实打实的兼容性补丁。少了它，很多浏览器会等脚本结束才刷新 DOM。另外，sleep(1) 在生产环境慎用，真实场景建议用异步或 SSE 替代。
真正难的不是写这几行函数调用，而是排查哪一层（PHP / Web server / reverse proxy / browser）悄悄把你的 chunk 吃掉了。每次失效，优先查 curl -v 响应头和实际传输流，别只盯着 PHP 代码。
