exec在循环中本质是反复fork+execve，每次触发完整进程创建：系统调用、调度、页表切换，开销固定且不可忽略；应优先合并命令或改用原生PHP函数替代。
exec在循环里调用，本质是反复 fork + execve
每次 exec 都会触发一次完整的进程创建流程：fork 子进程 → 加载新程序映像 → 执行 → 等待退出。这比函数调用重得多，不是“慢一点”，而是“开销固定且不可忽略”。100 次 exec 循环，就是 100 次系统调用 + 100 次进程调度 + 至少 100 次内存页表切换。
- Linux 上可用
strace -c php script.php验证：clone、execve、wait4三项调用次数会与循环次数严格对齐 - PHP 8.1 默认禁用
pcntl_fork（除非显式启用），但exec不依赖它，仍走系统 fork 路径 - 命令本身越快（如
echo、date），相对开销反而越明显——因为真正执行时间占比小，启动成本占比大
优先合并命令，而不是优化 exec 参数
别纠结 exec 的第四个参数或是否加 & 后台运行。真正有效的路径是：把 N 次独立命令，压成 1 次批量命令。例如处理文件列表：
- ❌ 错误模式：
foreach ($files as $f) { exec("convert {$f} -resize 200x {$f}.thumb.jpg"); } - ✅ 正确方向：
exec("mogrify -path ./thumbs/ -resize 200x *.jpg")（用 ImageMagick 原生命令批量处理） - 若工具不支持批量，就自己拼接：
$cmd = 'printf "%s\n" ' . escapeshellarg(implode(' ', $files)) . ' | xargs -r -n 50 convert -resize 200x' - 注意
escapeshellarg必须包裹每个文件名，不能只包整个字符串
用 proc_open 替代 exec 可控性更强，但不自动提速
proc_open 本身不会减少系统调用次数，但它能复用子进程 stdin/stdout 管道，避免重复 fork。适合需要持续交互的场景，比如调用 Python 解释器多次执行小段代码：
PHP 8.5.12 RC 1
下载
PHP 8.5.12 RC 1 候选版修复 BZ2、DOM、PDO、Opcache/JIT 和扩展内存安全问题，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
- 用
proc_open启动一个长期存活的 Python 进程，通过管道发送多条命令，再读取多条响应 - 对比：100 次
exec('python -c "print(1+1)"')→ 100 次 fork；1 次proc_open+ 100 次fwrite→ 1 次 fork - 但要注意：子进程异常退出后需手动重启，不能假设它永远健壮
- PHP 8.1 中
proc_open的suppress_errors参数已废弃，错误需靠返回资源判空或捕获Warning
绕过 exec：用原生扩展或内置函数替代外部命令
很多被 exec 调用的命令，PHP 本身就有等效能力，且零系统调用开销：
立即学习“PHP免费学习笔记（深入）”；
- 查文件信息？别
exec('stat -c "%y" file')，直接用filemtime()、filesize()，它们底层走stat()系统调用，但不用 fork - 生成随机字符串？别
exec('openssl rand -hex 16')，用random_bytes(16)+bin2hex() - 压缩/解压？用
gzencode()、zip_open()，而非exec('gzip') - JSON 处理？
json_encode()和json_decode()是 C 实现，比调jq快一个数量级
真正卡点往往不在 exec 本身，而在于没意识到 PHP 已经提供了更轻量的替代方案。批量命令合并和原生函数替换，这两步做完，90% 的循环 exec 场景性能就能回归合理区间。
