第一次在 Webpack 5 的内部实现讨论中看到 Comb Universe 这个词，很多人会以为是什么科幻项目的代号。实际上它是社区对 Webpack 5 内部模块图重构思路的一个形象化称呼：把整个项目的依赖关系看成一片混乱的宇宙，而构建器就像一把梳子，把纠缠在一起的模块依赖一根根梳理清楚。理解这个概念，对掌握 Webpack 5 的持久化缓存、模块去重和 Tree Shaking 行为都很有帮助。
一、Comb Universe 想解决什么问题
在 Webpack 4 及更早的版本中，依赖关系的收集和模块的挂载是相对松散的过程。一个模块在解析完成后，它的依赖信息分散在不同的数据结构里，chunk 划分阶段再重新组织一遍。这种做法在中小项目里问题不大，但当项目模块数量突破数万之后，就会出现两类典型痛点：一是缓存失效的粒度过粗，改一行代码可能导致大量模块重新构建；二是重复模块难以被准确识别，同一个包的不同副本会被多次打包。
Webpack 5 对内部数据结构做了系统性重写，引入了更加严格的模块图（ModuleGraph）和依赖引用（ModuleGraphConnection）体系。这就是梳子宇宙的核心：每一条依赖边都被显式记录，模块之间的引用关系不再是隐式的推断结果，而是可以精确遍历的图结构。这把梳子的齿间距是均匀的，每一根齿对应一条可追踪的依赖路径。
带来的直接收益是持久化缓存变得可靠。Webpack 5 的文件系统缓存之所以能做到增量构建，前提就是模块图中的每个节点都能独立计算哈希，某个模块变化时只有真正受影响的依赖链会失效，而不是整个 chunk 推倒重来。
二、如何在项目中体验依赖梳理机制
梳子宇宙并不是一个需要单独开启的配置项，它是 Webpack 5 的底层机制，但你可以通过合理的配置让它发挥最大效果。首先是启用持久化缓存，这是感受模块图精细化管理最直接的方式。
module.exports = {
cache: {
type: 'filesystem',
buildDependencies: {
// 配置文件本身变化时让缓存失效
config: [__filename]
},
cacheDirectory: path.resolve(__dirname, '.webpack_cache')
},
optimization: {
// 帮助模块图识别重复模块
moduleIds: 'deterministic',
splitChunks: {
chunks: 'all'
}
}
};上面的配置里，type: 'filesystem' 开启了磁盘缓存，第二次构建时 Webpack 会直接复用模块图中未变化的部分。实测大型项目二次构建速度通常能提升百分之七十以上，这正是模块级哈希带来的收益。
另一个值得关注的点是 sideEffects 字段。模块图在梳理依赖时，需要判断一个模块是否可以被安全地摇掉，package.json 中的副作用声明就是判断依据。
{
"name": "my-ui-lib",
"version": "1.0.0",
"sideEffects": false
}如果把整个包标记为无副作用，Webpack 在梳理依赖图时就能大胆地把未被引用的导出直接剔除。反过来，如果你的代码里确实存在需要保留的副作用（比如全局样式导入），就要精确地声明文件路径，否则梳子会把你需要的东西也梳掉，引发线上问题。
三、梳子宇宙与模块联邦的协作关系
Webpack 5 的另一个重量级特性是模块联邦（Module Federation），它允许多个独立构建的应用在运行时共享模块。梳子宇宙所建立的精确模块图，正是模块联邦能够工作的基础。
原因不难理解：当宿主应用要远程加载一个模块时，Webpack 必须清楚这个模块的依赖闭包里有哪些内容需要一起加载，哪些模块可以走共享依赖的协商机制。这些判断完全依赖模块图提供的精确引用关系。如果依赖信息是模糊的，运行时按需加载就无从谈起。
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'host',
remotes: {
remoteApp: 'remoteApp@http://127.0.0.1:3001/remoteEntry.js'
},
shared: {
react: { singleton: true },
'react-dom': { singleton: true }
}
})
]
};配置中的 shared 选项依赖模块图识别出哪些模块是共享候选，而 singleton 则保证共享依赖在运行时只保留一份实例。没有底层那把梳子把依赖理顺，这些上层能力都会变成空中楼阁。
四、常见误区与排查思路
第一个常见误区是认为开启了持久化缓存就一劳永逸。实际上 buildDependencies 配置不当，会导致缓存频繁失效或该失效时不失效。建议把 webpack 配置文件、babel 配置等纳入构建依赖，而版本升级后最好清一次缓存目录。
第二个误区是滥用 sideEffects: false。有些项目直接照搬别人的配置，把含有 polyfill 或 CSS 导入的入口也标记为无副作用，结果生产环境样式丢失。排查方法很简单：临时把 sideEffects 改为 true 再构建，如果问题消失，就说明是副作用标记的问题，然后逐文件精确声明。
第三个误区是忽视重复模块的来源分析。可以借助 webpack-bundle-analyzer 观察产物中同一个包是否出现多个版本。当模块图已经能精确去重，仍然出现重复时，往往问题出在 monorepo 中不同子项目依赖了同一个库的不同版本，需要在根 package.json 中统一版本或使用 resolutions 机制收敛。
总的来说，梳子宇宙代表的是 Webpack 5 对依赖治理的态度转变：从模糊打包转向精确建模。理解这套思路后，再去学习缓存、Tree Shaking、模块联邦这些特性，你会发现它们其实是同一套底层逻辑在不同层面的投影。写配置时多想一想模块图会怎么梳理你的依赖，很多构建问题就能在源头避免。
Webpack 5Comb Universe模块联邦修改时间：2026-09-04 10:17:00