exec() 和 proc_open() 默认均同步阻塞，高 CPU 主因是轮询等待子进程而非命令本身；真正降载需 bypass_shell、非阻塞流及主动超时控制。
exec() 会阻塞主线程并可能拉高 CPU，proc_open() 虽更灵活但默认仍同步等待，不加控制照样卡住 —— 关键不在函数选型，而在是否显式管理流阻塞与进程生命周期。
exec() 高 CPU 占用的真实原因
很多人以为 exec() 占 CPU 是因为“命令本身太重”，其实更常见的情况是：命令没输出、没退出，而 PHP 一直在轮询等待子进程状态。尤其在 Windows 下调用 start /min ffmpeg 这类命令时，exec() 实际等的是 start.exe 退出，但真正干活的 ffmpeg.exe 已脱离控制，导致 PHP 进程空转、CPU 持续 100%。
-
exec()无管道控制能力，无法设置超时或非阻塞读取 - 错误码和输出混在一起，
$return_var只能反映 shell 层退出状态，不是目标进程真实状态 - 在 CLI 模式下反复调用
exec()做轮询（比如检查文件生成），极易触发内核级忙等待
proc_open() 默认仍是同步阻塞
直接把 exec("ls -l") 换成 proc_open("ls -l", $desc, $pipes) 并不会自动降 CPU —— 因为 stream_get_contents($pipes[1]) 默认是阻塞读，且 proc_close() 会一直等到子进程彻底结束才返回。如果你没手动干预流行为，它只是“换了个姿势阻塞”。
- 必须对每个
$pipes[n]显式调用stream_set_blocking($pipes[1], false)才能避免读卡住 - Windows 下若未设
['bypass_shell' => true]，仍可能被 cmd.exe 包裹，PID 获取不准 -
proc_open()返回的资源不等于进程句柄，需配合proc_get_status()查真实运行状态
proc_open() 低资源占用的关键配置
真正让 proc_open() 跑得轻量，靠的是三件事：禁用 shell 封装、关闭流阻塞、主动轮询 + 超时退出。下面是最简可行组合：
PHP 8.5.12 RC 1 候选版修复 BZ2、DOM、PDO、Opcache/JIT 和扩展内存安全问题，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
立即学习“PHP免费学习笔记（深入）”；
$descriptorspec = [
0 => ['pipe', 'r'],
1 => ['pipe', 'w'],
2 => ['pipe', 'w']
];
$process = proc_open('ffmpeg -i input.mp4 -f null -', $descriptorspec, $pipes, null, null, [
'bypass_shell' => true // Windows 必加，绕过 cmd.exe
]);
if (is_resource($process)) {
stream_set_blocking($pipes[1], false);
stream_set_blocking($pipes[2], false);
$start = time();
while (time() - $start < 30) {
$status = proc_get_status($process);
if (!$status['running']) break;
usleep(10000); // 每 10ms 查一次，不忙等
}
proc_terminate($process, 9); // 强制终止残留
proc_close($process);
}
-
bypass_shell在 Windows 上必须开启，否则proc_get_status()['pid']返回的是 cmd.exe PID，不是 ffmpeg - 所有
$pipes都要设stream_set_blocking(false)，哪怕你只读 stdout - 别依赖
feof()判断输出结束 —— 很多命令（如tail -f、ollama run）根本不关 stdout
什么时候该放弃 proc_open() 改用消息队列
如果你发现即使加了非阻塞和超时，还是得写一堆 proc_get_status() 轮询逻辑，或者要同时管理十几个长期运行的子进程（比如批量转码），说明业务已超出 PHP 进程管理能力边界。
- PHP 不适合做长期后台任务调度器，
proc_open()是“临时借个壳”，不是“建个操作系统” - ffmpeg、ollama、python 脚本这类 IO 密集型命令，更适合丢进 RabbitMQ/Kafka，由独立 Worker 进程消费
- 一旦需要进程崩溃自动重启、资源配额限制、日志归集，就该切到 Supervisor + Docker 组合，而不是在 PHP 里硬扛
最常被忽略的一点：proc_open() 的 $pipes 数组必须在 proc_close() 前全部 fclose()，否则文件描述符泄漏，跑几个小时后系统 open files limit 就会耗尽 —— 这个问题不报错，只默默变慢。
