system只能获取退出码，无法捕获stdout/stderr；popen可读取stdout但stderr仍输出到终端；需同时捕获两者时须用fork+exec+pipe（Windows用CreateProcess）。
想快速跑个shell命令，比如 ls -l 或 ping -c 1 google.com，system 确实是最简单粗暴的选择。但它只返回退出码，并不给你 stdout 或 stderr 里的内容——这一点很多人容易搞混。
常见的误解是以为 system 能捕获输出。实际上，你写 int ret = system("echo hello");，ret 拿到的是 shell 进程的退出状态，通常需要通过 WEXITSTATUS(ret) 才能提取出 echo 命令本身的退出码。而 "hello" 这个输出，直接刷到终端上了，你的程序里根本存不住。
- 适用场景：只关心命令是否成功，不关心结果内容。比如备份前
system("mkdir -p /backup")，跑完就行。 - 注意 shell 注入风险：如果命令拼接了用户输入，必须严格过滤，或者改用
fork + exec。 - 阻塞调用：主线程会卡住，直到子进程结束。
- Windows 下也支持，但命令语法要适配，比如
system("dir")。
system函数执行命令但拿不到输出
想要真正拿到外部程序的输出，popen 是更轻量的方案。它返回一个 FILE*，你可以用 fgets、fread 读取子进程的 stdout。
典型错误是忽略 popen 的 mode 参数含义："r" 表示读子进程的 stdout，"w" 表示写入子进程的 stdin（此时你得自己处理子进程的输出）。绝大多数场景下，我们用的是 "r"。
- stderr 默认不重定向——子进程的错误信息还是会打到你的程序的 stderr 上，不会出现在
popen返回的流里。 - 必须配对调用
pclose，否则资源泄漏；pclose的返回值和system类似，需要用WEXITSTATUS提取真实退出码。 - 示例：
FILE* fp = popen("ls -A /tmp", "r"); char buf[256]; while (fgets(buf, sizeof(buf), fp)) { /* 处理每行 */ } pclose(fp); - 不跨平台：Windows 下可用，但行为略有差异，比如某些 cmd 特性不支持。
popen能读取stdout但不处理stderr
当你要把子进程的 stdout 和 stderr 都收进内存（比如做日志分析、自动测试断言输出），popen 就不够用了——它只管一条流。
这时候，得手动建两个 pipe，fork 后在子进程里用 dup2 把它们分别重定向到 STDOUT_FILENO 和 STDERR_FILENO，再 exec 目标程序。父进程从两个 pipe 读就行。
- 代码量明显增加，但完全可控：可以设超时、可以非阻塞读、可以区分哪行来自 stdout、哪行来自 stderr。
- 容易漏掉 close：父进程要关掉 pipe 的写端，子进程要关掉所有无关 fd，否则
read可能永远等不到 EOF。 - Windows 没有
fork，得用CreateProcess+ReadFile，逻辑更繁琐，建议封装成跨平台工具类。 - 别直接用
std::string拼接大输出：管道缓冲区有限，大量输出时得边读边处理，避免内存暴涨。
需要同时捕获stdout+stderr？绕不开fork+exec+pipe
如果项目里只在两三处调用外部命令，且只要简单执行或读一行输出，裸用 system 或 popen 更轻量、更易 debug。强行套一层“ProcessRunner”反而增加理解成本。
但如果你频繁需要：带超时、合并 stderr 到 stdout、捕获二进制输出、支持 Windows/Linux、还要传环境变量——那就值得封装。注意别重复造轮子：boost::process 已经覆盖了大部分需求，但引入 boost 是个权衡。
- 自己封装时，别把
std::string当作唯一接口：二进制数据（如图片压缩结果）要用std::vector或回调函数流式处理。 - 环境变量继承默认是全量的，敏感信息（如
API_KEY）需要显式清理，否则可能泄露。 - 子进程崩溃时，
waitpid可能返回-1或触发SIGCHLD，异常路径务必覆盖。
真正难的不是调用本身，而是错误边界：命令不存在、权限不足、磁盘满导致 pipe 写失败、子进程卡死、输出编码乱码……这些都得在真实环境里挨个踩过坑才记得住。
