system()会阻塞主线程且无法捕获输出，popen()可读取stdout但需pclose()防僵尸进程，二者均有安全与可移植性缺陷，c++标准库至今无跨平台进程api。
system() 会阻塞主线程，且无法获取命令输出
如果你只是想“运行一个命令然后继续”，system() 最简单，但它会挂起当前线程，直到命令退出。更重要的是，它不提供任何方式读取命令的 stdout/stderr —— 输出直接打到终端，你完全不可控。
常见错误现象：system("ls -l > /tmp/out.txt") 看似能保存结果，但实际依赖 shell 重定向，一旦 shell 不可用（比如 POSIX_SPAWN 模式或嵌入式环境）就失败；更隐蔽的问题是，它无法判断命令是否真的执行成功（system() 返回值是 shell 的退出状态，不是目标命令的）。
使用场景仅限于：调试打印、临时触发脚本、对输出和错误完全不关心的后台任务。
-
system()参数是完整命令字符串，由 shell 解析，存在注入风险（比如拼接用户输入时） - Windows 下调用
cmd.exe，Linux/macOS 下调用/bin/sh，行为不一致 - 返回值需用
WEXITSTATUS宏提取，直接比较0可能误判信号终止
popen() 能读输出但得自己处理进程生命周期
popen() 是更实用的选择：它返回一个 FILE*，你可以像读文件一样读命令的 stdout（或写入 stdin），同时避免了 shell 注入（如果不用 shell 模式）。
立即学习“C++免费学习笔记（深入）”；
但注意：它只支持单向管道（"r" 或 "w"），不能同时读写；而且你必须显式调用 pclose()，否则子进程变僵尸进程 —— 这是 C++ 新手最常漏掉的点。
示例片段：
FILE* fp = popen("ls -l", "r");
if (!fp) return;
char buf[1024];
while (fgets(buf, sizeof(buf), fp)) {
// 处理每行输出
}
pclose(fp); // 必须调用！否则资源泄漏- Windows 下
popen()不支持"w"模式（即不能向命令写入） - Linux 下默认经过
/bin/sh -c，仍可能有 shell 注入；如需规避，得用fork()+exec()组合 -
pclose()返回值也需用WEXITSTATUS解析，和system()一样
C++17 起没有标准跨平台执行命令的 API
别指望 <cstdlib></cstdlib> 之外有“更现代”的替代。C++ 标准库至今没提供 std::process 或类似设施（提案 P1165 仍在讨论中）。所有跨平台方案都得靠第三方库（如 Boost.Process）或自己封装系统调用。
这意味着：如果你需要 Windows/Linux 行为一致、支持超时、捕获 stderr、设置工作目录等，system() 和 popen() 都不够用，必须降级到 fork()/exec()（POSIX）或 CreateProcess()（Windows）。
- Boost.Process 接口清晰但引入较大依赖，编译时间明显增加
- 自己封装时，Windows 的
STARTUPINFO和 POSIX 的sigaction处理差异很大，容易漏掉信号屏蔽或句柄继承控制 - 所有方案都无法绕过权限问题：子进程权限不会高于父进程，且 Windows UAC 会拦截无权操作
安全与可移植性比“能不能跑”更重要
真正难的不是让命令跑起来，而是让它在不同环境里稳定、安全、可维护地跑起来。比如硬编码 "rm -rf /tmp/*" 在 macOS 上可能因空格路径崩溃；用 popen("python script.py") 在没装 Python 的机器上直接段错误；而 system() 调用含空格路径的程序（如 "C:\Program Files\app\run.exe"）在 Windows 下大概率失败。
最容易被忽略的一点：环境变量继承。子进程默认继承父进程的 PATH、LD_LIBRARY_PATH 等，但某些容器或沙箱环境会清空它们 —— 导致命令“明明存在却报 command not found”。这时候你得显式构造完整路径，或提前 setenv()。
