Webpack 的 Loader 和 Plugin 有什么区别？分别在构建的哪一步执行？

知识点详解：沿着一份文件，看两种扩展怎样工作

Loader 改的是模块交给下一步的内容

咱们假设入口文件引用了一个 TypeScript 模块。Webpack 解析依赖以后，需要把这个模块加入构建。但模块里的类型语法不能原样作为普通 JavaScript 处理，所以需要相应转换。

Loader 接收到模块内容，处理以后返回结果，Webpack 再继续分析。处理结果还可以包含 Source Map 等信息，不只是把一个字符串换成另一个字符串。

Webpack Loader 文档说明了规则匹配和链式处理。这里要注意：不是所有 Loader 都做语言转换。有的负责处理样式、资源或其他模块内容；分类依据是它怎样参与模块处理，而不是输出文件扩展名。

链式转换中，顺序会改变输入

假设配置为 use: ["style-loader", "css-loader"]，普通阶段先经过右侧的 css-loader，再经过左侧的 style-loader。

可以理解成接力：后一段处理依赖前一段的结果。如果把顺序反过来，下一个 Loader 接收到的内容就可能不是它能够处理的内容。

不过，Loader 还存在 pitch 阶段等机制，其方向与普通阶段不同，并可能影响后续执行。因此，面试中先说“普通阶段从右向左”，再补充特殊阶段，不要直接说“任何 Loader 永远从右向左”。

实际排查顺序问题时，要检查当前 Loader 的输入要求和文档，而不是把多个名称按印象排列。

Plugin 接的是构建事件，不是同一条转换链

Webpack 构建会经历建立依赖、生成模块、组织产物等过程。Plugin 可以在某个钩子上注册逻辑，等构建走到对应位置时执行。

例如生成构建报告，需要看到模块或产物信息；在合适的构建钩子里获取这些信息，比把报告生成逻辑塞进每个文件的 Loader 更合理。

Webpack Plugin 文档解释了这种扩展方式。同一个 Plugin 可以注册多个钩子，也可以参与较早的阶段。因此，“Loader 先执行、Plugin 最后执行”不是可靠的顺序描述。

更准确的关系是：模块转换发生在构建过程之中，Plugin 在它订阅的过程节点上参与工作。两者不是先后排队的两类插件。

根据需求选，而不是根据代码长短选

如果需求是删除某种源文件中的特殊标记，可以考虑模块转换。若需求是汇总整个构建中用了哪些模块，就需要构建级信息，Plugin 更符合这个需求。

当然，复杂扩展可能同时包含两种机制。判断时依旧要分清职责：哪部分改变模块内容，哪部分观察或调整构建状态。

验证时可以使用很小的项目，只放一个入口和两个模块。检查转换前后代码、Source Map 和生成产物；对于 Plugin，再检查它的钩子在什么条件下触发，开发监听模式下是否重复执行。小范围验证比直接放进大项目后看“能不能打包”更容易定位问题。

面试官继续追问

Babel 和 Loader 是什么关系？

Babel 是转换工具，babel-loader 是把它接入 Webpack 模块处理的适配。两者不是同一个东西，Babel 也可以不通过 Webpack 使用。

一个 Plugin 只能运行一次吗？

不是。监听模式、多次编译或不同钩子都可能让相关逻辑多次执行。需要按所订阅钩子的语义处理状态，不要把进程启动次数当成编译次数。

为什么不能用 Loader 做全局统计？

可能勉强实现，但模块处理存在缓存、并行和多次构建等条件。依赖副作用累积全局结果容易出错，应优先使用适合构建级工作的接口。

面试速记卡

• Loader：参与模块内容的处理与转换。
• Plugin：通过构建生命周期钩子扩展行为。
• 顺序边界：普通 Loader 链从右向左，特殊阶段另看机制。
• 常见误区：Plugin 不等于最后执行的 Loader。
• 选择依据：模块级转换，还是构建级协作。