system()用于执行shell命令，但存在阻塞、无输出、命令注入等风险，应避免处理用户输入；c++无标准进程api，推荐fork/exec或createprocess；需shell特性时须转义参数。
system() 函数能干啥，但别当万能钥匙用
system() 确实能执行 shell 命令，比如 system("ls -l") 或 system("pause")，但它本质是 fork + exec + wait，开一个新 shell 进程，等它退出才继续。这意味着：它阻塞主线程、不返回命令输出、无法传参给命令本身（只能拼字符串）、且 shell 依赖强——Windows 用 cmd.exe，Linux/macOS 用 /bin/sh。
常见错误现象：system("echo hello > output.txt") 在某些嵌入式环境或禁用 shell 的构建中直接失败；用 system("rm -rf " + path) 拼接用户输入，结果路径含空格或 ; 就触发命令注入。
- 只在调试、脚本胶水、或明确需要 shell 功能（如管道、重定向）时用
- 绝对不要用它处理用户可控的字符串
- 注意返回值：
system()返回的是子进程的wait()状态码，不是命令本身的退出码（得用WEXITSTATUS提取）
替代方案：用 std::process？C++17 没这玩意儿
C++ 标准库至今没提供跨平台进程管理接口。所谓“C++17 的 std::process”是误传——它从未进入标准，提案（P1165）也已搁置。目前可靠路径只有：
- POSIX 系统（Linux/macOS）：用
fork()+execvp()+waitpid()，绕过 shell，安全传参 - Windows：用
CreateProcessA/W()，同样不走cmd.exe - 第三方库：如
boost::process（需编译）、libuv（异步友好），但引入依赖要权衡
性能影响明显：system() 多一次 shell 解析开销；而 execvp() 直接加载目标程序，启动快 2–5 倍（尤其高频调用时）。
立即学习“C++免费学习笔记（深入）”；
Shell本身是一个用C语言编写的程序，它是用户使用Linux的桥梁。Shell既是一种命令语言，又是一种程序设计语言。作为命令语言，它交互式地解释和执行用户输入的命令；作为程序设计语言，它定义了各种变量和参数，并提供了许多在高级语言中才具有的控制结构，包括循环和分支。它虽然不是Linux系统核心的一部分，但它调用了系统核心的大部分功能来执行程序、建立文件并以并行的方式协调各个程序的运行。因此，对于用户来说，shell是最重要的实用程序，深入了解和熟练掌握shell的特性极其使用方法，是用好Linux系统
怎么安全拼接参数？别用字符串拼接
写 system(("grep " + keyword + " file.txt").c_str()) 是典型陷阱。keyword 含 $PATH、`date` 或引号时，shell 就会执行意外逻辑。
正确做法是彻底避开 shell：
- POSIX 下：用
fork()后，构造char* argv[] = {"grep", "-e", keyword.c_str(), "file.txt", nullptr}，再execvp("grep", argv) - Windows 下：用
CreateProcess()，把参数放进lpCommandLine时必须整体加双引号，且内部引号要转义（如"\"hello world\""） - 如果真需要 shell 特性（比如
|或&&），先对所有变量做 shell 转义（shellescape），再拼接——但绝大多数场景其实不需要
Windows 上 system("pause") 为啥有时卡住？
这不是 bug，是行为预期：它依赖 cmd.exe 执行 pause 内部命令，而 pause 会等待任意键，包括 Ctrl+C —— 但 Ctrl+C 默认触发进程终止信号，导致控制台未清理就退出，看起来像“卡住”。
更稳的方式：
- 用
getchar()替代（仅读回车，不依赖 shell） - 或调用 Windows API：
system("echo Press any key... && pause >nul")加>nul屏蔽提示，减少干扰 - 注意控制台模式：若程序以
CREATE_NO_WINDOW启动，system()可能静默失败，毫无提示
跨平台可执行文件里混用 system() 和终端交互，最容易在 CI 环境（无 TTY）下挂死——这点常被忽略。
