std::system最快但最不安全，因启动完整shell易受注入攻击；posix_spawn/CreateProcess绕过shell更安全；popen仅单向通信且仍经shell；C++26前推荐用boost::process等成熟库。
用 std::system 最快但最不安全
直接执行 Shell 命令，std::system 是最省事的选择，但它会启动完整 shell（如 /bin/sh），命令字符串会被 shell 解析——这意味着你得自己处理空格、引号、重定向、管道，稍有不慎就执行了意料之外的命令。
常见错误现象：std::system("rm -rf /tmp/" + filename) 中若 filename 是 "a; rm -rf /"，后果严重；或者路径含空格时直接截断。
- 只用于可信输入、调试打印、一次性脚本调用（比如
std::system("date > /tmp/log.txt")） - 永远不要拼接用户输入进
std::system字符串 - 返回值是 shell 退出码，不是命令本身退出码（需用
WEXITSTATUS提取） - Windows 下调用的是
cmd.exe，行为和 POSIX shell 不一致
用 posix_spawn 或 fork+exec 精确控制参数
真正需要安全、可控地跑外部程序时，得绕过 shell，直接构造进程参数。POSIX 系统推荐 posix_spawn（C++17 起可直接用，无需手动 fork）；Windows 则用 CreateProcess。
使用场景：启动一个带多个参数、不含 shell 特性的程序，比如 grep -n "error" /var/log/syslog，且参数来自变量。
立即学习“C++免费学习笔记（深入）”；
-
posix_spawn第二个参数是程序路径（如"/usr/bin/grep"），第三个是argv数组指针，每个元素必须是const char*，结尾为nullptr - 参数里不能写
"-n error"这种合并字符串，必须拆成argv[0]="grep", argv[1]="-n", argv[2]="error", ... - 不会解析
|、>、$HOME，想重定向就得自己dup2文件描述符 - 比
std::system启动略慢，但无注入风险，适合生产环境
std::popen 能读输出但不能交互
如果只需要捕获命令 stdout（比如 ls -l 的结果），std::popen 比 std::system 多一步读取能力，但它本质仍是走 shell，且只能单向通信（读或写，不能同时）。
常见错误现象：调用 popen("cat file | grep keyword", "r") 看似方便，但管道逻辑由 shell 执行，依然受注入影响；更糟的是，忘记 pclose 会导致子进程僵死、文件描述符泄漏。
- 只用于简单、可信的命令，且只需单向流（例如获取
git rev-parse HEAD输出） - 返回
FILE*，用fgets读，别用std::cin或operator>>混用 - Windows 下
popen不支持"w"模式（不能往命令 stdin 写） - 无法获取命令真实退出码，
pclose返回值需用WEXITSTATUS解包
跨平台封装建议：别硬写宏，用 std::process 等待 C++26
C++23 没有标准进程库，C++26 才计划加入 std::process。现在硬写 #ifdef _WIN32 / #else 容易漏掉信号处理、编码（Windows 控制台默认 GBK）、路径分隔符等细节。
性能与兼容性影响：自己封装 fork/exec 和 CreateProcess 表面统一了接口，但 Windows 上 CreateProcess 对参数的空格处理、引号转义规则和 POSIX 完全不同，极易在边界 case 失败（比如参数含反斜杠或双引号）。
- 短期方案：用成熟轻量库，如
boost::process（头文件少、不依赖 Boost 其他模块）或ghc::filesystem配套的 process 小工具 - 避免自己实现超时、kill 子进程、等待任意子进程等功能——信号和句柄管理太容易出错
- 如果只是调用几个固定命令，写成 shell 脚本或批处理，C++ 只负责
std::system调用，反而更稳
真正麻烦的从来不是“怎么启动”，而是“怎么确保它按预期结束、没残留、没权限越界、输出没乱码”。这些点，std::system 全部甩给你自己扛。
