Webpack 5 在内部架构上做了一次幅度不小的重构，其中一个非常值得关注的演进方向就是构建流程的管道化设计，社区里有人形象地称之为 Duct Universe（管道宇宙）。简单来说，它把原本散落在各个编译阶段、通过大量 Hook 串联起来的逻辑，重新组织成一条条职责清晰的管道，数据像水流一样在管道之间流转，每个管道节点只关心自己的输入和输出。这种设计思路对于理解 Webpack 5 的模块联邦、持久化缓存以及更快的增量构建都有直接帮助。理解管道宇宙，本质上是理解 Webpack 5 如何组织一次完整的打包。
一、从 Hook 体系到管道模型的演进动机
在 Webpack 4 及更早的版本中，整个构建流程是靠 tapable 提供的各类 Hook（SyncHook、AsyncSeriesHook 等）串联起来的。Compiler 和 Compilation 对象上挂载了上百个 Hook，插件开发者需要精确地知道在哪个 Hook 上挂载逻辑，才能在正确的时机介入构建。这种方式在插件数量少的时候运作良好，但当构建规模变大、插件数量变多时，问题就暴露出来了。
第一个问题是执行顺序不透明。多个插件挂载在同一个 Hook 上时，它们之间的依赖关系只能靠 before、after 这类相对定位参数来约束，一旦插件之间存在隐式依赖，构建结果就变得难以预测。第二个问题是数据流不清晰。Hook 本质上是一个事件广播机制，它并不关心数据从哪里来、到哪里去，一个 Hook 的回调修改了内部状态，下游的 Hook 只能隐式地感知这种变化，调试和追踪的成本很高。
管道模型针对这些问题给出了不同的答案：每个阶段被建模为一个独立的管道，管道内部由若干处理单元组成，数据以显式的形式从一个处理单元流向下一个处理单元。Webpack 5 中的模块请求解析、模块构建、依赖收集、代码生成、产物优化等环节，都逐步向这种组织方式靠拢。这种重构带来的直接收益是：构建过程中的中间结果可以被缓存（这正是持久化缓存的实现基础之一），某个阶段的输出可以独立测试，阶段之间可以按需并行执行。
二、管道宇宙的核心构成与数据流转
管道宇宙可以被拆解为三条主干管道来理解。第一条是请求管道，负责处理从入口出发的模块请求。resolve 阶段把一个裸的模块标识符（比如 ./utils/format）转换为绝对路径，并附带描述文件信息。这条管道的输出是一个个 module 对象的工厂请求，它们随后被送入模块工厂创建真正的模块实例。
第二条是模块构建管道。模块实例创建后，需要经过 Loader 转换、AST 解析、依赖收集三个子阶段。Webpack 5 在这里做了重要的流水线化改造：Loader 的执行被组织为一个可缓存的处理链，转换后的源码交给 javascript/parser 解析出依赖描述，这些依赖描述又被送到下一段处理。整个过程可以用下面的伪代码来理解其结构：
class Module {
build(resolver, fs, options) {
return this._doBuild(resolver, fs, options, (err) => {
// 1. 执行 loader 链，得到转换后的源码
const source = this._source;
// 2. 解析源码，收集依赖
const deps = parser.parse(source);
// 3. 将依赖写入模块，等待下一阶段处理
this.dependencies = deps;
});
}
}第三条是产物生成管道，包含代码生成（模块的 runtime 代码包装）、分块（chunk graph 的构建）、优化（tree shaking、代码压缩、模块合并）以及最终写出文件。这条管道的特点是优化器被组织为一组可插拔的处理单元，每个单元消费 chunk 级别的数据并输出处理后的结果，例如 OptimizeModuleIdsPlugin、ConcatModulesPlugin 都以这种形态存在。
三、在 Loader 与 Plugin 开发中应用管道思想
理解管道架构不只是满足好奇心，它对日常的工程实践有直接指导意义。首先，写 Loader 时应该严格遵循单一职责原则：一个 Loader 只做一次转换，输入字符串、输出字符串，不要在 Loader 里做副作用操作（比如写文件、发起网络请求）。因为管道化的构建系统会根据 Loader 的输入输出和缓存配置来决定是否复用上次的转换结果，一旦 Loader 内部掺杂了不可追踪的副作用，缓存就会失效甚至产生错误的复用，导致构建结果不可复现。
module.exports = function (source) {
// 只做纯粹的字符串转换，保持管道单元的可组合性
return source.replace(/__VERSION__/g, this.version || '0.0.0');
};其次，写 Plugin 时应当尽量把逻辑拆分为细粒度的 Hook 监听，而不是在一个 Hook 里做所有事情。管道化的思维要求每个处理步骤边界清晰、输入输出明确，这样 Webpack 才能更好地调度缓存与并行。比如你需要在构建完成后生成一个资源清单，正确的做法是监听 compilation.hooks.processAssets 并在其中操作 assets 集合：
class ManifestPlugin {
apply(compiler) {
compiler.hooks.compilation.tap('ManifestPlugin', (compilation) => {
compilation.hooks.processAssets.tap(
{ name: 'ManifestPlugin', stage: 100 },
(assets) => {
const manifest = Object.keys(assets).join('\n');
compilation.emitAsset('manifest.txt', {
source: () => manifest,
size: () => manifest.length
});
}
);
});
}
}最后，从性能角度看，管道化架构配合 experiments.cache（文件系统持久化缓存）能带来显著的二次构建提速。因为管道的每个阶段输出都是可序列化的中间结果，缓存命中时可以跳过整段处理单元的执行。配合 Webpack 5 的多进程 thread-loader 替代方案以及按需编译的懒编译特性，大型项目的冷启动与热更新体验都有明显改善。建议在实际项目中开启持久化缓存并观察各阶段的耗时分布，针对最慢的那段管道做定向优化，这比盲目堆砌优化插件有效得多。
总结来看，Duct Universe 并不是某个可以直接在配置文件里开启的开关，而是 Webpack 5 内部架构演进的一种设计取向：以显式的数据流取代隐式的事件广播，以可缓存的管道单元取代黑盒式的阶段函数。掌握这种思维方式，无论是排查构建性能问题，还是编写高质量的插件，都会让你在面对复杂工程化场景时更加从容。
Webpack 5Duct Universe模块打包修改时间：2026-09-01 07:19:00