system只能获取退出码，无法捕获stdout/stderr；popen可读取stdout但stderr仍输出到终端；需同时捕获两者时须用fork+exec+pipe（Windows用CreateProcess）。
system函数执行命令但拿不到输出
想快速跑个 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")）
popen能读取stdout但不处理stderr
popen 是真正能拿到外部程序输出的轻量方案，它返回 FILE*，你可以用 fgets、fread 读取子进程的 stdout。
典型错误是忽略 popen 的 mode 参数含义："r" 表示读子进程 stdout，"w" 表示写入子进程 stdin（此时你得自己处理子进程的输出）。绝大多数场景用 "r"。
立即学习“C++免费学习笔记（深入）”；
- 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 特性不支持）
需要同时捕获stdout+stderr？绕不开fork+exec+pipe
当你要把子进程的 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拼接大输出：管道缓冲区有限，大量输出时得边读边处理，避免内存暴涨
要不要用C++封装？看维护成本和需求粒度
如果项目里只在两三处调用外部命令，且只要简单执行或读一行输出，裸用 system 或 popen 更轻量、更易 debug。强行套一层“ProcessRunner”反而增加理解成本。
但如果你频繁需要：带超时、合并 stderr 到 stdout、捕获二进制输出、支持 Windows/Linux、还要传环境变量——那就值得封装。注意别重复造轮子：boost::process 已覆盖大部分需求，但引入 boost 是个权衡。
- 自己封装时，别把
std::string当作唯一接口：二进制数据（如图片压缩结果）要用std::vector<char>或回调函数流式处理 - 环境变量继承默认是全量的，敏感信息（如
API_KEY）需显式清理，否则可能泄露 - 子进程崩溃时，
waitpid可能返回-1或触发SIGCHLD，异常路径务必覆盖
真正难的不是调用本身，而是错误边界：命令不存在、权限不足、磁盘满导致 pipe 写失败、子进程卡死、输出编码乱码……这些都得在真实环境里挨个踩过坑才记得住。
