根本原因是popen返回的FILE*流默认带缓冲，子进程stdout未主动flush导致fgets卡住；应禁用缓冲、用fgets()!==false判断读取、合并stderr并用stream_select实现非阻塞轮询。
为什么 fgets 读不到实时输出，或者卡在第一行不动
根本原因是 popen() 返回的 FILE* 流默认带缓冲，而子进程（比如 yt-dlp、ping 或自定义 PHP 脚本）的 stdout 没有主动 flush，导致 PHP 端 fgets() 一直等不到换行或 EOF。更隐蔽的问题是：用 !feof($fp) 做循环条件不可靠——EOF 标志只在真正读失败后才置位，不是“数据还没来”的信号。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- Linux 下必须对
$fp调用stream_set_blocking($fp, true)（虽然默认就是 true，但显式声明更稳） - 避免依赖
feof()判断循环终止；改用fgets($fp) !== false作为读取条件 - 子进程命令末尾加
2>&1，否则 stderr 会丢失（比如 PHP 警告、权限错误全看不到） - 如果子进程是自己写的 PHP 脚本，记得每输出一行后调用
fflush(STDOUT)
如何安全地并发启动多个 popen 进程并分别读取
popen() 本身不支持并发控制或超时，多个句柄共存时容易因某个子进程 hang 住，拖垮整个主脚本。关键不是“怎么开多个”，而是“怎么不被卡死”。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 把每个
popen()调用包进try/catch，并检查返回值是否为false（popen()失败时直接返回false，不是异常） - 不要用
while (!feof($fp))长时间阻塞读取；改用非阻塞 + 轮询：先stream_select()检查句柄是否可读，再fgets() - 每个句柄设独立超时逻辑，例如：记录
microtime(true)启动时间，每次读取前判断是否超 30 秒 - Windows 下慎用
popen()并发——它不支持双向通信，且某些 shell 命令行为不一致
pclose 之前必须确保输出读完，否则子进程可能僵死
pclose() 会等待子进程退出，但如果子进程还在写 stdout、而你已经提前关闭了读端（比如 fclose($fp)），系统管道可能卡住，子进程就永远等不到 write() 返回，变成僵尸状态。
PHP 8.5.12 RC 1 候选版修复 BZ2、DOM、PDO、Opcache/JIT 和扩展内存安全问题，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 读取循环必须持续到
fgets()返回false，而不是只读几行就停 - 不要在读取中途调用
pclose()；务必等fgets()明确失败后再关 - 调用
pclose()后检查返回值：若为-1，说明子进程异常终止（比如被 signal kill） - 如果子进程预期长期运行（如
tail -f），别用popen()——改用proc_open()配合proc_terminate()
PHP8.1 下 popen 的兼容性与替代提醒
PHP8.1 保留了 popen()，但它的底层行为没变，依然受限于 libc 的 popen(3) 实现。真正要注意的是：PHP8.1 默认开启 strict_types=1 的文件不会影响 popen()，但它会让类型错误更早暴露——比如把 int 当作 string 传给命令拼接，会直接报错而非静默转字符串。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 命令字符串必须完整拼好再传给
popen()，不要在popen()调用里做字符串插值（易注入）；用escapeshellarg()包裹用户输入 - 如果需要 stderr 单独处理、或向子进程写入数据，
popen()不够用，必须上proc_open() -
readfile()和shell_exec()完全不适合流式场景——它们要么全量缓存，要么不返回句柄，无法实时干预
最常被忽略的一点：popen 启动的进程，其工作目录是 PHP 主脚本所在目录，不是 Web 根目录，也不是 $_SERVER['DOCUMENT_ROOT']；路径错误导致的“命令找不到”或“文件不存在”，往往查半天才发现是 cwd 问题。
