我使用 LaTeX 大约一个月了，每当我有问题时，大多数答案都涉及在序言中添加新包。
我的问题是，这些软件包如何工作？它们都包含在源代码中，只等着在序言中启动吗？
为什么它们没有全部激活（预先启动），而需要手动插入？
如果这一切都是在本地完成的，不使用互联网，那么就会引发另一个问题：您是否可以使用来自在线来源的软件包而无需手动下载它们？如果不行，这是在计划中吗？
答案1
软件包只是带有命令的 tex 文件，您可以在自己的文档中定义这些命令。许多软件包本质上是选项，没有必要同时加载字体软件包：或脚注样式和其他布局选择的软件包等。
如果现在设计 LaTeX，它可能会有更多的预加载格式的代码，但在 1993 年 LaTeX2e曾是\label设计时，在加载后，文档中大约有 100 个命令（包括）的空间amsmath，因此，选择不加载此类包是一个至关重要的选项。事实上，多年来，LaTeX 发布的autoload版本中，部分代码（如图片模式和制表符）默认情况下未预加载，并且本质上是包（如果使用环境，则会自动加载）。这是为文档中更多的用户命令和交叉引用留出空间。
加载包文件所花费的时间通常并不那么重要，但是如果您大量使用加载大量包的类，则可以将它们预加载为个人格式。（例如，参见mylatexformat）。
答案2
我想说的是好的LaTeX 不会预加载大量软件包。正如 David Carlisle 所解释的那样，这是由于 1990 年代机器的计算能力较弱的历史原因造成的，但其结果非常有用。
举个例子。除了 LaTeX2e 之外，还有一些软件包作为任何 LaTeX 发行版的组成部分发布，其中包括enumerate。这是自定义枚举列表的一个很好的补充，但已被更强大的软件包（如 ）所取代enumitem。
假设enumerate已经成为 LaTeX 的一部分而不需要单独加载；那么我只会看到两种利用 功能的可能性enumitem：
- 作为单独的包加载
enumitem，即今天所做的事情； - 与 LaTeX集成
enumitem，但可能会破坏以enumerate功能为目的编写的文档。
其他示例。哪种高级图形软件包会被选为 LaTeX 的一部分？PSTricks 还是 TikZ？或者，也许是mfpic？如果前者成为 LaTeX 的一部分，我们可能就不会有pdflatex，因为它在许多功能上与 PSTricks 不兼容，或者我们会有一个禁用 PSTricks 的 PDFLaTeX 格式：这肯定会引发“格式战争”，也就是说，同一个 LaTeX 的版本略有不兼容。这正是发布 LaTeX2e 的原因之一：结束不同 LaTeX 2.09 版本的繁衍（一个适用于荷兰语，一个适用于德语，一个适用于 A4 纸，另一个适用于俄语等等）。
子目录计数<texlive2012>/tex/latex返回 1731。这意味着远不止 1731 个包，因为这些目录通常包含多个包。其中几个几乎已经消失，仅用于向后兼容。如果这些已经集成到 LaTeX 内核中，那么我在enumerateversusenumitem示例中展示的问题将会成倍增加。
这就是软件包这个主意的好处：你不必再受困于二十年前从某个角度编写的东西，因为这个角度可能表明它不够通用。新软件包可以以更简洁、更好的方式解决旧问题，但二十年前编写的文档仍然可以排版而无需更改。
这与编程语言的情况并没有什么不同。人们是否会加载全部他们的程序是否需要 C 库？Perl 脚本是否会在一次运行中加载整个 CPAN？相反，您没有 LibreOffice 或类似软件的库/包：你得到的只是他们给予的. 并且旧文档很容易与新版本的软件冲突。
答案3
(La)TeX 的优点之一是它是完全可编程的。因此，许多人会创建自己的命令集，有时当他们认为这些命令对其他人有用时，会将它们作为软件包发布。
我确实同意一些（基本）功能可以包含在 LaTeX“基础”中，但不要忽视这样做的难度，例如
- (La)TeX 支持的输出范围非常广泛，从巨幅海报到大型多卷书籍，包括图表、演示文稿、简历、乐谱等，因此，对于一个应用程序来说可能是“基本”的东西，对于另一个应用程序来说可能完全没用，
- 对于特定的应用程序，并不是每个人都同意应该包含哪些“基本”功能，
- 即使对于特定应用程序的某些所谓已达成一致的“基本”功能，也总是存在不同的实现方法，而且它们通常彼此不兼容！
答案4
包裹如何运作？
包是 Latex 中标准化的扩展机制。Latex 本身由 Tex 宏组成，包也是如此，Latex 定义了允许执行包的 Tex 代码的命令和接口结构。还有一个庞大的社会基础设施使包机制发挥作用，通过 CTAN 存储库以及通过努力使 Tex Live 和 Miktex 等大型发行版顺利运行。
为什么包没有预先初始化？
Latex 中软件包的重要性以及典型的 Latex 文档需要导入许多软件包，这是 90 年代决定通过这种软件包机制进行发展的结果，而其他基于 Tex 的文档准备系统则试图集中发展。Context 就是其中之一，我见过的大多数 Context 文档只导入模块（软件包的 Context 对应部分）来加载字体。其他的一般都已经消亡了。
Latex 模型的最大优势在于探索新功能，从而产生了诸如 memoir 和 KOMA 脚本包等出色的成果。但代价是 Latex 社区中存在各种不同的方法来做类似的事情，而且包在语法上存在冲突，有时交互效果不好。
Latex 3 努力的主要目标之一就是通过指定统一的接口并将更多在标准包中完成的工作合并到基础系统中来使其合理化。在保持 Latex 社区的支持的同时做到这一点是一项英勇的努力，并且将继续是一项英勇的努力，就像用机器牧羊犬（其操作系统仍在开发中）来放牧猫一样。
是否可以按需从互联网加载软件包
Miktex 可以“动态”加载包；Tex Live 目前不支持（参见Joseph Wright，‘Windows 上的 TEX：MiKTEX 还是 TEX Live？’、TUGboat）。另请参阅texliveonfly对于 Unix。
附加问题：还有其他选择吗？
正如我提到的，背景是最重要的竞争方法；有一些信息在我们的上下文标签 wiki 中。
Plain Tex 没有有意义的包机制：本质上，您将一些 Tex 代码放入 TEXMF 目录中\input，这只占 Latex 对其包系统所做的一半，但没有有意义的抽象来处理诸如重复加载请求、查询已加载的内容等问题。存在一些 Tex 代码来尝试强加结构。使用字体时，缺乏包结构是最痛苦的。