我正在试图弄清楚将CLI工具（以及可能的其他程序）拆分成多个可执行文件的原因。
例如Git和Cargo都遵循这种方法，其中有一个可执行文件（git或cargo）基本上只解析给定的参数（例如init或update所以调用是git init或cargo update），然后调用另一个可执行文件。
所以基本上Git或Cargo的所有命令都是通过外观调用的单个可执行文件。
我正试图围绕这个架构来更好地理解它的好处。
显然，这是一种不仅在源代码级别而且在分发级别实现模块化的方法。
但即使这样也可以通过在目录中抛出库（而不是可执行文件）并通过主可执行文件加载所有这些来实现。我之前使用.NET构建了类似的插件架构。
但这不是Git或Cargo所做的。据我所知，他们使子命令真正的可执行文件被称为带参数的进程。这不是比图书馆方法更昂贵吗？我想知道它的好处是什么？
我试图弄清楚这种方法是否仅适用于CLI工具，但不适用于性能关键的东西。就像Git一样，还有lib2git，它似乎是Git重新实现的一个库。
我想知道在为其他语言编写绑定时，大量可执行文件方法是否具有优势。但是，如果我们只有一个可执行文件并从目录中加载子命令作为库，那么通过调用主可执行文件来编写来自其他语言的绑定应该同样简单。
我看到的one-executable-plus-multiple-sublibraries方法的唯一不足之处可能是启动时间，如果它必须在启动时加载所有子库。
对这个话题有更好理解的人能否为我提供一些启示？
答案 0 :(得分：2)
开发交互式CLI应用程序时，两种方法之间的性能影响无关紧要。瓶颈总是用户输入一个命令，几个数量级。
工具套件名为“Git”或“Cargo”的事实并不意味着它是一个工具。它是一个由许多单独工具组成的大型系统，每个工具对文件系统所代表的数据集执行不同的原子操作。
如果期望每个组件都是一个大型应用程序的一部分，那么库方法是合理的。这里情况不同。这是一组工具，甚至需要每个工具的人都不希望每次想要调用函数时都必须编写主机应用程序来利用库的API。您可能会建议在库中包含一个名为“Git.exe”的父EXE，它接受参数并利用这些库（这基本上就是我们已经拥有的，除了您现在强迫消费者使用）使用主机可执行文件重定向或b]编写一个全新的应用程序），但现在你需要每次执行这个东西时动态加载和卸载一大堆库。如果您只需要在需要时只调用其功能需要的那个，那会不会很棒？
通过原子可执行文件集合引入模块化，可以非常轻松地保持关注点分离，记录每个命令的确切输入/输出，并为套件提供脚本编写接口，无需编写额外代码：只需调用您需要的可执行文件。
编写一个引用所提议的.DLL集合子集的应用程序并在每次要在例如一个例子上运行多个命令时编译成单个.EXE会更高效吗？ Git存储库？绝对。这样做的时间和精力是否值得花费时间和精力来制作一个Bash脚本，该脚本调用四个.EXE背靠背传递一些选项作为参数？几乎没有。
当然还有其他原因我没有想过要解决，我会非常有兴趣阅读您发现的有关此问题的任何其他信息。希望我已经给你一些建立查询的东西。