webpack中的加载器和插件有什么区别？
documentation for plugins只是说：
使用插件添加通常与webpack中的bundle相关的功能 .
我知道babel使用加载器进行jsx / es2015转换，但看起来像其他常见任务（例如copy-webpack-plugin）使用插件 .
当您在代码中使用类似 require("my-loader!./my-awesome-module") 的情况时，装载程序会对几乎任何文件格式进行预处理转换 . 与插件相比，它们非常简单，因为它们（a）只向webpack公开一个函数，（b）不能影响实际的构建过程 .
require("my-loader!./my-awesome-module")
另一方面，插件可以深入集成到webpack中，因为它们可以在webpacks构建系统中注册钩子并访问（和修改）编译器，它是如何工作的，以及编译 . 因此，它们更强大，但也更难维护 .
增加补充和简单的答案 .
Loaders:
在生成 bundle 期间或之前，加载程序在单个文件级别工作 .
Plugins:
插件工作在 bundle 或 chunk 级别，通常在捆绑生成过程结束时工作 . 插件还可以修改捆绑包本身的创建方式 . 插件比装载器具有更强大的控制能力 .
举个例子，您可以在下面的图片中清楚地看到装载机正在工作以及插件工作的位置 -
参考文献：Article和Image
装载机工作在file level . 他们可以编写模板，根据您的方便等处理一些代码来进行转换 .
插件工作在system level . 他们可以处理模式，文件系统处理（名称，路径）等 .
从本质上讲，webpack只是一个文件捆绑器 . 考虑到一个非常简单的场景（没有代码拆分），这可能只意味着以下操作（在高级别上）：
找到条目文件并将其内容加载到内存中
匹配内容中的某些文本并对其进行评估（例如@import）
根据以前的评估查找依赖项，并对它们执行相同的操作
将它们全部拼接成内存中的一个包
将结果写入文件系统
当您仔细研究上述步骤时，这与Java编译器（或任何编译器）的作用产生共鸣 . 当然存在差异，但是理解加载器和插件并不重要 .
装载机：
在这里是因为webpack承诺将任何文件类型捆绑在一起 .
由于webpack的核心功能足以捆绑js文件，因此这个承诺意味着webpack核心团队必须整合构建流程，允许外部代码以webpack可以使用的方式转换特定的文件类型 .
这些外部代码称为加载器，它们通常在上面的步骤1和3中运行 . 因此，由于这些加载器需要运行的阶段是显而易见的，它们不需要挂钩，也不会影响构建过程（因为构建或捆绑仅发生在步骤4） .
因此，Loaders准备了编译阶段，它们扩展了webpack编译器的灵活性 .
插件：
在这里，因为即使webpack不直接承诺变量输出，世界也想要它，而webpack确实允许它 .
由于webpack的核心只是一个捆绑包，并且在这样做的过程中经历了几个步骤和子步骤，因此可以利用这些步骤来构建其他功能 .
例如，生成构建过程（缩小和写入文件系统）是webpack编译器的本机能力，可以被视为其核心能力的扩展（它只是捆绑）并且可以被视为本机插件 . 如果他们没有提供它，其他人就会这样做 .
看看上面的原生插件，似乎可以将webpack捆绑或编译分解为核心捆绑过程，以及我们可以关闭或自定义或扩展的许多本机插件过程 . 这意味着允许外部代码在他们可以选择的特定点（称为钩子）中加入捆绑过程 .
因此，插件会影响输出并扩展webpack编译器的功能 .
4 回答
当您在代码中使用类似
require("my-loader!./my-awesome-module")的情况时，装载程序会对几乎任何文件格式进行预处理转换 . 与插件相比，它们非常简单，因为它们（a）只向webpack公开一个函数，（b）不能影响实际的构建过程 .另一方面，插件可以深入集成到webpack中，因为它们可以在webpacks构建系统中注册钩子并访问（和修改）编译器，它是如何工作的，以及编译 . 因此，它们更强大，但也更难维护 .
增加补充和简单的答案 .
Loaders:
在生成 bundle 期间或之前，加载程序在单个文件级别工作 .
Plugins:
插件工作在 bundle 或 chunk 级别，通常在捆绑生成过程结束时工作 . 插件还可以修改捆绑包本身的创建方式 . 插件比装载器具有更强大的控制能力 .
举个例子，您可以在下面的图片中清楚地看到装载机正在工作以及插件工作的位置 -
参考文献：Article和Image
装载机工作在file level . 他们可以编写模板，根据您的方便等处理一些代码来进行转换 .
插件工作在system level . 他们可以处理模式，文件系统处理（名称，路径）等 .
从本质上讲，webpack只是一个文件捆绑器 . 考虑到一个非常简单的场景（没有代码拆分），这可能只意味着以下操作（在高级别上）：
找到条目文件并将其内容加载到内存中
匹配内容中的某些文本并对其进行评估（例如@import）
根据以前的评估查找依赖项，并对它们执行相同的操作
将它们全部拼接成内存中的一个包
将结果写入文件系统
当您仔细研究上述步骤时，这与Java编译器（或任何编译器）的作用产生共鸣 . 当然存在差异，但是理解加载器和插件并不重要 .
装载机：
在这里是因为webpack承诺将任何文件类型捆绑在一起 .
由于webpack的核心功能足以捆绑js文件，因此这个承诺意味着webpack核心团队必须整合构建流程，允许外部代码以webpack可以使用的方式转换特定的文件类型 .
这些外部代码称为加载器，它们通常在上面的步骤1和3中运行 . 因此，由于这些加载器需要运行的阶段是显而易见的，它们不需要挂钩，也不会影响构建过程（因为构建或捆绑仅发生在步骤4） .
因此，Loaders准备了编译阶段，它们扩展了webpack编译器的灵活性 .
插件：
在这里，因为即使webpack不直接承诺变量输出，世界也想要它，而webpack确实允许它 .
由于webpack的核心只是一个捆绑包，并且在这样做的过程中经历了几个步骤和子步骤，因此可以利用这些步骤来构建其他功能 .
例如，生成构建过程（缩小和写入文件系统）是webpack编译器的本机能力，可以被视为其核心能力的扩展（它只是捆绑）并且可以被视为本机插件 . 如果他们没有提供它，其他人就会这样做 .
看看上面的原生插件，似乎可以将webpack捆绑或编译分解为核心捆绑过程，以及我们可以关闭或自定义或扩展的许多本机插件过程 . 这意味着允许外部代码在他们可以选择的特定点（称为钩子）中加入捆绑过程 .
因此，插件会影响输出并扩展webpack编译器的功能 .