应避免在关键逻辑中使用system()，因其不安全、不可控、难调试：易卡住或返回-1，依赖shell导致跨平台行为不一致，无法获取真实退出码和标准输出，且存在命令注入风险；推荐linux/macos用fork()+exec()组合、windows用createprocess()替代。
别用 system() 做关键逻辑，它不安全、不可控、难调试。
为什么 system() 会卡住或返回 -1
常见现象是程序“假死”几秒后才继续，或者直接返回 -1 —— 这通常不是你命令写错了，而是 shell 启动失败或权限被拦截。Windows 下如果没设好环境变量（比如找不到 cmd.exe），Linux 下如果 /bin/sh 被删或 PATH 损坏，system() 就会直接失败。
-
system()依赖系统默认 shell，不同平台行为不一致（Windows 用cmd.exe，Linux/macOS 用/bin/sh） - 它会阻塞当前线程，且无法获取子进程的 stdout/stderr
- 返回值只有成功/失败（0 或 -1），没法拿到真实 exit code（除非你自己解析
WEXITSTATUS，但 Windows 没这玩意） - 命令字符串会被 shell 解析，存在注入风险：
std::string cmd = "rm -rf " + user_input;→ 千万别这么干
替代方案：Linux/macOS 用 fork() + exec() 组合
想真正控制子进程、捕获输出、避免 shell 解析，就得绕过 system()，自己 fork+exec。这是 POSIX 标准做法，也是 system() 内部实际调用的底层逻辑。
- 先
fork()创建子进程，再在子进程中调用execvp()（推荐）或execv()，传入程序路径和参数数组 - 父进程用
waitpid()等待并获取真实退出码，而不是只看system()的粗略返回值 - 如果要读输出，得提前用
pipe()创建管道，重定向子进程的stdout，再read()读取 - 注意：
exec系列函数不会返回，失败时需手动exit()，否则子进程会继续跑父进程后续代码
Windows 下怎么安全执行命令
Windows 没有 fork()，但 CreateProcess() 是等价替代，而且更可控。它不经过 cmd 解析，默认也不启动新窗口（除非显式设 CREATE_NO_WINDOW）。
Shell本身是一个用C语言编写的程序，它是用户使用Linux的桥梁。Shell既是一种命令语言，又是一种程序设计语言。作为命令语言，它交互式地解释和执行用户输入的命令；作为程序设计语言，它定义了各种变量和参数，并提供了许多在高级语言中才具有的控制结构，包括循环和分支。它虽然不是Linux系统核心的一部分，但它调用了系统核心的大部分功能来执行程序、建立文件并以并行的方式协调各个程序的运行。因此，对于用户来说，shell是最重要的实用程序，深入了解和熟练掌握shell的特性极其使用方法，是用好Linux系统
立即学习“C++免费学习笔记（深入）”；
- 用
CreateProcess()替代system()，传入完整路径（如"C:\Windows\System32\ping.exe"）比依赖PATH更可靠 - 通过
STARTUPINFO设置hStdOutput和hStdError句柄，配合管道捕获输出 - 别用
ShellExecute()执行命令行工具——它专为打开文档/URL 设计，对ping、curl这类工具返回值不可靠，还可能弹窗 - 注意宽字符：如果项目是 Unicode 编译模式，要用
CreateProcessW()，参数全为wchar_t*
什么时候真能用 system()？
仅限开发机上快速验证、脚本化构建步骤、或完全可信的静态命令（比如固定路径的清理脚本）。生产环境、用户输入参与拼接、需要错误分类处理的场景，一律避开。
- 可以接受：
system("mkdir build && cd build && cmake ..");（仅本地调试） - 不能接受：
system(("grep " + keyword + " file.txt").c_str());（shell 注入） - 不能接受：
system("python3 script.py > out.log");（重定向失效，log 文件为空，因为 shell 解析被绕过） - 跨平台项目尤其要警惕：同一行
system()在 Windows 和 Linux 上可能一个成功一个报错，比如system("sleep 1")在 Windows 直接失败
真正麻烦的从来不是“怎么调起命令”，而是“命令挂了怎么知道”“输出在哪”“它到底有没有执行成功”。这些细节，system() 一概不管。
