std::system最快但最不安全，仅返回shell退出码且无法捕获输出；易受命令注入攻击，跨平台行为不一致，应优先用std::filesystem等标准库替代。
用 std::system 最快但最不安全
直接执行命令行指令，std::system 是最短路径：它把字符串交给 shell（Windows 是 cmd.exe，Linux/macOS 是 /bin/sh）运行。比如 std::system("ls -l") 或 std::system("dir")。
但它有硬伤：无法获取输出、无法判断具体失败原因、容易被注入攻击——只要用户输入拼进命令字符串，就可能执行任意指令。
常见错误现象：std::system("rm -rf " + path) 中 path 含空格或分号，导致删错目录；或返回值只检查是否为 -1，却忽略 shell 自身失败（如找不到命令）。
- 返回值是 shell 的退出码，不是命令本身的；需用
WEXITSTATUS（POSIX）或直接对比system()返回值与0 - Windows 下不支持管道、重定向等 shell 语法（除非显式调用
cmd /c） - 跨平台时，命令名和参数风格必须手动适配（如
lsvsdir）
用 std::popen 拿输出但得自己收尾
std::popen 能读取命令输出，适合需要结果文本的场景，比如解析 git status 或 df -h。它返回 FILE*，可用 fgets 逐行读。
立即学习“C++免费学习笔记（深入）”；
但它是 C 风格接口，C++ 里没 RAII 封装，容易忘记 pclose；且只能单向通信（要么读输出，要么写输入，不能同时）。
- 必须用
pclose关闭，否则子进程变僵尸，文件描述符泄漏 - 只支持
"r"（读输出）或"w"（写输入），不能双向；想传输入又读输出得用更底层的fork+exec - Windows 下
popen不支持"w"模式（MSVC 限制），且换行符处理和 POSIX 不一致 - 示例：
auto fp = popen("ps aux | grep myapp", "r");—— 注意管道在 shell 层解析，不是popen本身能力
跨平台要避免硬编码命令名
写死 "ls" 或 "dir" 会让程序在另一系统直接崩溃。更稳妥的方式是：优先用 C++ 标准库（如 std::filesystem）替代简单命令；非用命令不可时，查环境变量或运行时探测。
-
std::filesystem::directory_iterator可替代ls/dir，std::filesystem::space替代df - 必须调外部命令时，用
getenv("OS")（Windows）或uname系统调用区分平台，再选命令名 - 参数空格处理：不要拼接字符串，改用
std::quoted(path)（C++20）或手动加双引号 - 避免依赖 shell 内置命令（如
echo,cd），它们在system中行为受 shell 版本影响
真正需要双向交互或精细控制，绕不开 fork+exec（POSIX）或 CreateProcess（Windows）
如果要同时给子进程输数据、捕获 stdout/stderr、设置超时、限制资源，system 和 popen 都不够用。这时得直面系统 API。
POSIX 下典型流程：先 pipe() 创建管道，fork() 分叉，子进程用 dup2() 重定向 stdin/stdout，再 execv() 执行；父进程关掉无关 fd，用 read()/write() 通信。
Windows 下用 CreateProcess 配合 STARTUPINFO 设置 hStdInput 等句柄，再用 ReadFile/WriteFile。
- 这两套 API 完全不兼容，封装成统一接口成本高；多数项目会引入
boost::process或libuv等库来屏蔽差异 - 子进程异常退出时，需用
waitpid（POSIX）或WaitForSingleObject（Windows）回收，否则僵死 - 信号处理要小心：
system会忽略SIGINT，但自己fork出来的进程默认继承父进程信号掩码
std::filesystem 或网络/进程间通信替代；真要调，优先考虑 popen + 显式 pclose，再不行才上系统 API。最常被忽略的是：没检查子进程是否真的执行了目标命令，还是仅仅启动了 shell 就返回成功。 
