shell_exec()需完整缓存stdout至内存再返回字符串，存在内存分配与拷贝开销，大输出易OOM；system()流式输出、无额外缓存，适合只展示不处理的场景。
shell_exec() 和 system() 的执行开销差异在哪
两者底层都调用系统 shell（如 /bin/sh），但 shell_exec() 需要捕获全部 stdout 到内存再返回字符串，而 system() 是边读边输出、不缓存——这意味着：shell_exec() 会多一次内存分配 + 字符串拷贝，尤其当命令输出大（比如 tar -czf 日志归档、find /var/log -name "*.log" -exec cat {} \;）时，内存占用和延迟明显更高；system() 则几乎没有额外开销，适合“只看结果、不处理”的场景。
输出内容大时 shell_exec() 容易触发 OOM 或超时
PHP 默认内存限制（memory_limit）通常为 128M 或 256M。若命令输出超过该阈值，shell_exec() 会直接失败并返回 NULL，且不抛异常，容易被忽略；system() 不受此限，只要 Web 服务器（如 Nginx）未中断连接，就能持续流式输出。
- 典型错误现象：
shell_exec('journalctl -n 10000')在低配容器中返回NULL，但system()能完整刷出 - 调试方法：执行后立即检查
error_get_last()，看是否含Allowed memory size exhausted - 替代方案：对大输出命令，优先用
system()+ 前端流式解析，或改用popen()分块读取
system() 的输出缓冲行为在 CLI 和 Web 下表现不同
在 Web SAPI（如 Apache/FPM）中，system() 输出会经过 PHP 输出缓冲层，若未显式 ob_flush() + flush()，浏览器可能等整个响应结束才渲染；而 CLI 模式下它默认实时打印。这不是函数本身问题，而是 SAPI 行为差异。
PHP 8.5.12 RC 1 候选版修复 BZ2、DOM、PDO、Opcache/JIT 和扩展内存安全问题，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
- Web 环境下想“真正实时”，需配合：
ob_implicit_flush(true); ob_end_flush(); - 注意 Nginx 的
proxy_buffering off和fastcgi_buffering off配置，否则仍会被代理层缓存 -
shell_exec()没这个问题，但它根本没“实时”能力——必须等全部执行完才返回
安全边界其实一样，别因性能放松过滤
性能差异不影响安全性本质：shell_exec() 和 system() 同样会因拼接用户输入导致 RCE。PHP 8.2 并未加强任一函数的沙箱能力，escapeshellarg() 对两者都有效，但绕过手段（如空字节、$IFS、反引号嵌套）在两类函数中同样生效。
立即学习“PHP免费学习笔记（深入）”；
- 常见误判：“用
system()就不用管返回值，所以更‘简单’” → 实际上它仍需检查第二个参数$return_var判断命令是否真成功 - 真实风险点：日志导出类功能常同时用到两个函数，开发者对
shell_exec()加了过滤，却在system()分支漏掉，形成绕过入口 - 最稳妥做法：统一走
proc_open()+ 显式指定环境变量 +['pipe', 'r']句柄控制，彻底避免 shell 解析
shell_exec() 适合短输出、需后续 PHP 处理的场景（比如 git rev-parse HEAD）；system() 更适合运维脚本透传、大文件生成、交互式调试——但它的“实时性”依赖整条链路（PHP、Web Server、Client）的缓冲配置，这点最容易被当成理所当然而踩坑。 
