当您require("my-loader!./my-awesome-module")在代码中使用sth时，加载程序几乎可以对任何文件格式进行预处理转换。与插件相比，它们非常简单，因为它们（a）仅向webpack公开一个功能，并且（b）无法影响实际的构建过程。

Plugins on the other hand can deeply integrate into webpack because they can register hooks within webpacks build system and access (and modify) the compiler, and how it works, as well as the compilation. Therefore, they are more powerful, but also harder to maintain.

加载程序在文件级别工作。他们可以编写模板，处理一些代码以根据您的方便进行翻译等。

插件在系统级别工作。他们可以处理模式，文件系统处理（名称，路径）等。

webpack的核心只是文件捆绑器。考虑到一个非常简单的场景（不拆分代码），这可能意味着（高层）以下操作：

1. 查找条目文件并将其内容加载到内存中
2. 匹配内容中的某些文本并进行评估（例如@import）
3. 根据先前的评估找到依赖项，并对它们进行相同的处理
4. 将它们全部缝合到内存中
5. 将结果写入文件系统

当您仔细检查以上步骤时，这会与Java编译器（或任何编译器）的行为产生共鸣。当然有区别，但是对加载程序和插件的理解无关紧要。

装载机：

之所以在这里是因为webpack承诺将任何文件类型捆绑在一起。

由于webpack的核心仅具有捆绑js文件的能力，因此，这一承诺意味着webpack核心团队必须合并构建流程，该流程允许外部代码以webpack可以使用的方式转换特定文件类型。

这些外部代码称为加载程序，它们通常在上述步骤1和3中运行。因此，由于这些装载机需要运行的阶段很明显，因此它们不需要挂钩，也不会影响构建过程（因为构建或捆绑只发生在步骤4）。

因此，加载器为编译做好了准备，它们在某种程度上扩展了webpack编译器的灵活性。

外挂程式：

之所以在这里，是因为即使webpack不能直接承诺变量输出，但全世界都希望得到它，而webpack确实允许它。

由于webpack的核心只是捆绑程序，而这样做却要经历几个步骤和子步骤，因此可以利用这些步骤来构建附加功能。

生产构建过程（最小化并写入文件系统）是webpack编译器的本机功能，例如，可以将其视为其核心功能的扩展（仅捆绑），并且可以将其视为本机插件。如果他们不提供，其他人会做。

查看上面的本机插件，似乎可以将webpack捆绑或编译分解为核心捆绑过程，以及可以关闭或自定义或扩展的许多本机插件过程。这意味着允许外部代码在他们可以选择的特定点（称为挂钩）加入绑定过程。

因此，插件会影响输出，并会扩展Webpack编译器的功能。

Adding complementary and simpler answer.

Loaders:

Loaders work at the individual file level during or before the bundle is generated.

Plugins:

插件在捆绑软件或块级别工作，通常在捆绑软件生成过程结束时工作。插件还可以修改捆绑包本身的创建方式。插件具有比加载程序更强大的控制功能。

仅举一个例子，您可以在下面的图片中清楚地看到加载器在工作，插件在工作-

参考： 文章和 图片