如果终端命令可以通过system();执行同样的操作，我应该使用win32函数吗？比如，使用win32函数创建文件和使用system("echo >> file.txt");有什么区别。
如果终端命令可以通过
system();执行同样的操作，我应该使用win32函数吗？
这会征求意见，但我会冒险说：几乎永远不要使用system()。
实际使用它的一类原因是，如果你需要使用一个没有库/API的程序，但它有一个可以理解的命令行界面。我把system()的所有用法都放在中，作为最后的手段bin。这几乎不是你应该追求的目标。
例如，使用win32函数创建文件和使用
system("echo >> file.txt");有什么区别。
Windows和Posix平台上的system()调用会创建一个子进程(默认为cmd.exe、/bin/sh或任何shell(来执行该命令。然后，主进程只等待子进程完成。
当程序员通常对创建文件是否成功感兴趣时，这个子shell必须解释命令，验证它，并将各种无意义的消息打印到stdout。所有这些通常需要比只调用手头的API多得多的系统资源。
外壳也是不同的野兽，有不同的版本，所以如果部署在目标平台的不同版本上，你的程序可能会表现得不同。如果您的程序链接到正确的库，则在程序启动时不会检测到这种情况。不同的shell具有不同的安全漏洞，使用system()的程序在历史上曾被成功攻击。由于您可能不知道您使用的shell的版本，因此您也无法控制这一部分。
也就是说，我不建议直接调用WinAPI来完成您的示例所做的工作。使用标准C++应该做得很好：
if(std::ofstream os("file.txt", std::ios::app); os) { // c++17 init-statement
os << 'n';
} else {
// failed opening "file.txt" for writing
}
编辑：dxiv指出，当使用cmd.exe作为外壳时，我的建议并不像echo >> file.txt那样。这显然是等价的：
os << "ECHO is on.n";
正如dxiv所指出的强化了"；可以表现得不同">和"；打印各种毫无意义的消息"；。
system()创建一个命令解释器的新实例(cmd.exe(，并在其中运行指定的命令。创建一个新进程会有很大的开销，所以只有在绝对需要的情况下才应该这样做。这是一个愚蠢的类比，但它就像在说，嗯，我需要一台冰箱，我会建一整栋房子，这样我就可以使用冰箱了。
此外，您会发现，如果使用system()，您的程序将无法访问创建的进程的stdin和stdout，而无需进一步的工作。因此，除了读取返回代码之外，您无法了解它做了什么。
与调用Windows API函数来完成任务相比，这要快得多，因为它们没有进程创建开销，提供了丰富的错误代码，除此之外，还提供了比cmd.exe更多的功能。