system() 不自动触发 flush，需手动调用 ob_flush() 和 flush() 才能实时输出；受 Web 服务器（如 Nginx fastcgi_buffering）、浏览器及 gzip 压缩等多层缓冲影响，仅改 PHP 层无效。
system() 默认不触发 flush，输出全量后才刷到浏览器
调用 system() 时，它的输出行为和 PHP 的输出缓冲机制是解耦的——它把命令的标准输出直接写入当前 stdout（即 PHP 的输出流），但**不会自动调用 flush() 或 ob_flush()**。这意味着即使命令执行中持续打印日志，PHP 仍可能把所有内容攒在输出缓冲区里，直到脚本结束或缓冲区满才一次性推给浏览器。
常见错误现象：system('ping -c 10 google.com') 执行 10 秒，页面却全程白屏，最后“啪”一下弹出全部 10 行结果。
- 根本原因不是
system()本身阻塞，而是 PHP 输出缓冲未被主动刷新 - 即使设置了
implicit_flush = On，system()的输出也未必实时可见（受 Web 服务器、浏览器、gzip 压缩等多层缓冲影响） - Apache + mod_php 环境下尤其明显；Nginx + PHP-FPM 则更依赖
fastcgi_buffering off配合
想边执行边看到输出？必须手动组合 ob_flush() + flush()
要实现“命令执行中逐步显示”，不能只靠 system()，得配合输出控制函数手动清空缓冲链路：
PHP 8.5.12 RC 1
下载
PHP 8.5.12 RC 1 候选版修复 BZ2、DOM、PDO、Opcache/JIT 和扩展内存安全问题，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
- 先调用
ob_implicit_flush(true)或ini_set('implicit_flush', 1)，让每条 echo/print 自动 flush（但对system()无效，仅辅助后续调试输出） - 更可靠的做法：在
system()前后加ob_flush()和flush()，并确保没有 gzip 压缩干扰 - 示例关键片段：
ob_end_flush(); // 清掉上层可能存在的缓冲 ob_start(); // 开新缓冲（可选，便于控制） system('tail -f /var/log/app.log | head -n 20'); ob_flush(); flush(); - 注意：
ob_flush()推送到 PHP 输出层，flush()才真正尝试发给客户端；两者缺一不可
Web 服务器和浏览器会吃掉你的 flush
即使 PHP 层 flush 成功，Nginx、Apache、甚至 Chrome 都可能二次缓冲，导致“明明调了 flush 却没反应”：
立即学习“PHP免费学习笔记（深入）”；
- Nginx 默认开启
fastcgi_buffering on，必须显式关掉：fastcgi_buffering off;（在 location 块中） - Apache 的
mod_deflate或mod_filter会拦截并缓存输出，需禁用或设置SetEnv no-gzip 1 - Chrome 对小于 1KB 的响应体有最小缓冲策略，可在输出开头加 1024 字节空白（如
str_repeat(' ', 1024)）绕过 - PHP-FPM 的
buffer_output = no（php-fpm.conf）也需确认关闭
替代方案：passthru() 更适合流式输出场景
如果目标就是“原样透传命令输出”，passthru() 比 system() 更合适：
-
passthru()不捕获输出、不截断最后一行，也不做任何处理，直接把子进程 stdout 写入当前输出流，语义上更接近“管道直通” - 它和
system()一样不自动 flush，但因无中间字符串拼接，配合ob_flush()/flush()时延迟更低、行为更可预测 - 使用示例：
header('Content-Type: text/plain; charset=utf-8'); header('X-Accel-Buffering: no'); // Nginx 专用头 passthru('ls -la /tmp | tail -n 10'); ob_flush(); flush(); - 注意：
passthru()返回值恒为null，失败时才返回false，别依赖返回值判断内容是否输出
fastcgi_buffering 和浏览器的初始缓冲门槛——光改 PHP 层代码，90% 的情况都看不到效果。 
