std::system 是最快启动并等待外部命令的方式，但无法获取输出、需手动处理退出码、不跨平台且存在 shell 注入风险；C++ 标准库至今无 std::process::Command。
用 std::system 最快启动并等待，但无法获取输出或精确控制
如果你只需要等外部命令跑完、不关心它的标准输出、也不需要捕获退出码以外的信息，std::system 是最轻量的选择。它直接调用系统 shell（Windows 是 cmd.exe，Linux/macOS 是 /bin/sh），阻塞当前线程直到子进程结束。
常见错误是忽略返回值含义：它返回的是 shell 的退出状态，不是你启动的程序的原始退出码。在 POSIX 系统上需用 WEXITSTATUS 宏提取；Windows 上可直接用。
-
std::system("ping -c 1 google.com")在 Linux 下有效，但"ping -n 1 google.com"才是 Windows 写法 —— 跨平台时得自己判断 OS - 如果命令含空格或特殊字符（如
my script.sh），必须加引号：std::system(""my script.sh" arg1")，否则 shell 可能拆分错误 - 不能重定向输出到内存缓冲区，
std::system("ls > out.txt")会写文件，但你拿不到内容
用 CreateProcess（Windows）或 fork+exec（POSIX）才能真正接管子进程
要读取子进程 stdout/stderr、设置超时、避免 shell 注入、或精确等待指定 PID，必须绕过 shell，直接创建进程。Windows 和 POSIX 接口差异大，没法一套代码通吃。
Windows 下用 CreateProcess 后必须配对调用 WaitForSingleObject，且注意 STARTUPINFO 中的 hStdOutput 等字段要设为管道句柄才能捕获输出。
立即学习“C++免费学习笔记（深入）”；
- POSIX 下
fork()返回 0 是子进程，需立刻调用execvp("ls", argv)；非 0 是父进程，用waitpid(pid, &status, 0)等待 - 子进程若未
exec就退出，父进程waitpid会拿到异常终止信号（如status中WIFSIGNALED(status)为 true） - 忘记在子进程中关闭管道读端（
close(pipefd[1])），父进程read可能永远阻塞
std::process::Command？C++ 标准库目前没有这个东西
别被 Rust 或 Python 的命名误导 —— C++20/23 标准库至今没提供跨平台进程管理 API。std::process 是假想名，实际不存在。网上有些文章提到它，要么是混淆了语言，要么引用了某个实验性提案（如 P1165），但未进入标准。
这意味着：所有“跨平台启动外部程序”的方案，本质都是你自己封装 CreateProcess 和 fork/exec，或依赖第三方库（如 Boost.Process、cpp-subprocess）。
- Boost.Process 看似方便，但编译依赖多，Windows 下需链接
boost_filesystem和boost_system - 轻量替代可考虑 immer 风格的单头库（如
process.hpp），但得自己验证其信号处理和 Unicode 路径支持 - 用
std::string拼接命令行时，Windows 路径含反斜杠和空格（如"C:\Program Files\App\tool.exe"）极易出错，建议统一用正斜杠或转义
超时等待和僵尸进程是生产环境最容易漏掉的点
只调用 waitpid 或 WaitForSingleObject 默认是无限等待。一旦子进程卡死或挂起，你的主程序就彻底堵住。更麻烦的是，如果父进程没及时 wait，子进程退出后会变成僵尸进程（Linux）或保持句柄占用（Windows）。
- POSIX 下用
waitpid(pid, &status, WNOHANG)轮询 +nanosleep实现超时，比alarm更可靠（alarm会中断系统调用） - Windows 下
WaitForSingleObject(hProc, timeout_ms)返回WAIT_TIMEOUT后，应主动TerminateProcess并再次WaitForSingleObject清理句柄 - 多线程环境下，一个线程
fork后，其他线程的状态不会复制到子进程 —— 这意味着子进程里只有调用fork的那个线程存在，其余线程已消失
路径、编码、权限、信号屏蔽、资源泄漏 —— 这些细节堆叠起来，比写个排序算法容易出错得多。
