Webpack 5 相比 Webpack 4 最大的变化不只是新增了几个配置项，而是从底层架构上强调了一种叫 Coherence（连贯性）的设计理念。简单来说，它希望同一个项目在任何时间、任何机器、任何环境下执行构建，都能得到逻辑上一致的结果。这个理念渗透在持久化缓存、确定性模块 ID、模块联邦等多个特性中。理解了连贯性，很多 Webpack 5 的改动就不再是零散的知识点，而是一套有内在逻辑的体系。
什么是 Webpack 5 的连贯性设计
在 Webpack 4 时代，很多团队都遇到过这样的问题：本地构建和 CI 构建产出的文件哈希不一致，明明代码一行没改，重新打包后缓存全部失效。这些问题的根源在于构建过程存在不确定性，比如模块 ID 采用自增整数、依赖的遍历顺序受文件系统返回顺序影响等。Webpack 5 把这些不确定因素逐一消除，让构建过程成为纯函数：输入相同，输出必然相同。
连贯性主要体现在三个层面。第一是缓存连贯性，通过文件系统持久化缓存配合内容哈希，实现增量构建的可靠复用；第二是模块标识连贯性，默认使用确定性算法生成模块 ID，不再依赖模块的发现顺序；第三是跨应用连贯性，模块联邦让多个独立构建的应用之间可以共享模块，且版本协调机制保证运行时行为一致。这三层共同构成了 Coherence 的完整含义。
持久化缓存与确定性模块 ID 的实现原理
先看缓存。Webpack 5 移除了 cache: true 这种基于内存的模糊配置，改为显式的文件系统缓存，开启方式如下：
module.exports = {
cache: {
type: 'filesystem',
buildDependencies: {
// 配置文件变更时让缓存失效，保证配置与产物一致
config: [__filename]
}
}
};缓存的有效性依赖于内容寻址。Webpack 5 内部对每个模块计算哈希时，会将其依赖、源码、使用的 loader 及其选项全部纳入计算范围。任何一个环节发生变化，对应模块的缓存条目就会失效，而其他未受影响的模块仍然可以复用。这种细粒度的失效策略正是连贯性的体现：缓存命中与否完全由内容决定，而非构建的时机或机器。
再看模块 ID。Webpack 4 中开发环境默认使用路径作为 ID，生产环境则使用数字 ID，且数字由模块被发现的顺序决定。文件系统返回文件的顺序在不同平台上可能不同，导致 ID 分配不稳定。Webpack 5 的 optimization.moduleIds 默认值为 deterministic，它基于模块路径的哈希生成一个固定长度的数字 ID：
module.exports = {
optimization: {
// deterministic 是默认值，基于路径哈希生成 3 位以上数字 ID
moduleIds: 'deterministic',
// chunk ID 同样采用确定性策略
chunkIds: 'deterministic'
}
};这样即使新增或删除模块，未受影响的模块 ID 也不会变化，直接带来的收益是产物的文件名哈希更稳定，浏览器的长效缓存命中率显著提升。相对地，natural 按使用顺序分配，named 使用可读路径但产物体积更大，一般只在调试时使用。
模块联邦如何实现跨应用的连贯协作
连贯性不仅是单个构建内部的事，Webpack 5 的模块联邦把它扩展到了多个独立部署的应用之间。微前端架构下最头疼的问题是共享依赖的版本冲突：宿主应用和远程应用各自打包一份 React，运行时可能出现两个不同版本的实例共存，引发钩子失效等诡异问题。
模块联邦的解法是让宿主在运行时声明它可以提供的模块，远程应用如果发现宿主已经提供了某个依赖，就不再加载自己的副本：
// 远程应用的 webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'remoteApp',
filename: 'remoteEntry.js',
exposes: {
'./Button': './src/components/Button'
},
shared: {
// 声明共享依赖，单例模式保证全局只有一个实例
react: { singleton: true, requiredVersion: '^18.0.0' }
}
})
]
};关键在 shared 配置中的 singleton: true。它保证无论宿主和远程各自声明什么版本范围，运行时只会加载一份实例，并且当版本不满足要求时会在控制台抛出错误，而不是静默地产生行为不一致。这种显式的冲突检测机制，正是连贯性理念在跨应用边界的延伸：模块的提供者和消费者之间有一套协商协议，而不是靠约定俗成。
需要注意的是，共享模块的异步加载意味着远程入口的加载时序必须处理好。如果宿主在共享依赖尚未就绪时就渲染了远程组件，会得到 undefined。可以在宿主侧通过 initialize 或动态 import 先等待共享依赖就绪，再挂载远程模块，从时序上保证一致性。
迁移到 Webpack 5 后保持构建连贯的实践建议
首先是清理废弃配置。Webpack 5 移除了不少与连贯性冲突的旧特性，例如 Node.js polyfill 的自动注入。以前 process、path 等模块会默认被填充，现在需要显式声明 resolve.fallback 或者在前端代码中避免直接依赖 Node API。如果不处理，构建会在运行时静默失败，这与连贯性的目标背道而驰，所以宁可让构建期报错，也不要让错误潜伏到线上。
其次是利用构建统计工具验证确定性。可以在 CI 中加入产物哈希比对步骤，对两次构建的输出目录做内容级别的 diff，如果代码和依赖没有变化而哈希不同，说明配置中仍有不稳定因素。常见的原因包括：配置里引用了时间戳或随机数、插件内部依赖了机器特定的路径、以及 output.filename 使用了会变动的变量。定位到这些点后逐一消除，构建就真正做到了可复现。
最后是合理配置缓存失效边界。buildDependencies 应包含所有影响构建逻辑的文件，比如 babel 配置、postcss 配置以及自定义的构建脚本。范围太小会导致配置变更后仍复用过期缓存，范围太大又会让缓存频繁失效。一个实用的判断标准是：凡是修改后需要重新打包才能生效的文件，都应该列入其中。团队协作时建议将缓存目录排除在仓库之外，但保留配置的版本控制，这样每个人拿到的缓存策略是一致的，连贯性也就有了制度保障。
Webpack 5Coherence 连贯性模块联邦修改时间：2026-09-10 06:00:38