Webpack 5 正式版发布时带来了许多重磅改进，但其中最有意思的并不是某个单一功能，而是一种整体思路的转变——它越来越像一个精明的「客户经理」，帮你搞清楚工程里每一个模块从哪里来、做了什么、跟谁有关系。这种思路我们可以戏称为构建工具里的 KYC（Know Your Customer）。当然，这里要了解的「客户」不是真实的用户，而是组成应用程序的成百上千个 JavaScript 模块、图片、样式文件等。理解了这些依赖的身份、来源和变动规律，我们才能真正做好性能优化、体积治理和跨项目共享。
依赖可视化：stats 不是数字，是一份客户档案
在 Webpack 4 时代，运行 webpack --json > stats.json 就能输出一份巨大的 JSON 统计文件，里面包含了所有模块信息、Chunk 组成、时间消耗等。但多数人只是拿它去给分析工具（比如 webpack-bundle-analyzer）生成一张图，看完就扔了。Webpack 5 并没有移除这份 stats，而是让它的结构更规范、信息更丰富，甚至可以作为一份长期保存的「客户档案」来使用。
对同一个项目做两次构建，如果两次的 stats 差异很小，说明你的依赖没有波动；如果某次构建 stats 里的 modules 数组突然多了十几个 node_modules 下的包，就表示有人引入或升级了依赖。在 CI/CD 流水线中，可以通过对比前后两次 stats 的 module.id 和 module.reasons 字段，自动发现新增的「高风险客户」——比如某个库体积巨大、带有多版本副本，或者引用了 Node 核心 API 却没有标记为 external。这比肉眼 review package.json 可靠得多，因为我们看到的是 Webpack 实际解析出来的模块图谱，而不是声明文件里写的那几个名字。
更进一步，Webpack 5 在 stats 配置中增加了 relatedModules 选项，能够让每个模块关联到它的 issuer（引用者），形成双向关系链。举个例子，当你发现一个组件反复被多个页面 chunk 包含，stats 就能帮你定位到所有引用路径，判断是否需要将其提取为公共模块。这种深度的依赖映射，就像给每个模块建立了一份包含「家庭住址」「工作关系」「收入来源」的客户卡片，让优化决策不再靠猜。
持久化缓存：让构建过程记住每一个客户变动的历史
在 Webpack 4 里，每次冷启动都要从零开始解析所有模块，哪怕你只改了一个字符串。Webpack 5 最大的架构突破之一就是内置的持久化缓存（Persistent Caching），它能把模块和 chunk 的编译结果以缓存形式存放到文件系统。这样第二次启动时，Webpack 会先读取缓存，只重新处理那些「客户信息发生变更」的模块，其它全部复用。
实现这一点的技术关键是模块级别的「etag」或「content hash」。Webpack 5 会为每个模块计算一个哈希值，这个哈希由源文件内容、loader 链、配置项等共同决定。只要哈希没变，模块就是「老客户」，可以直接跳过编译。配置文件里只需简单开启：
module.exports = {
cache: {
type: 'filesystem',
buildDependencies: {
config: [__filename] // 当配置文件变化时缓存失效
}
}
};
缓存开启后，Webpack 内部会生成一个 .webpack/cache 目录（或自定义位置），里面存储着二进制的缓存数据。这个过程类似于银行为每个客户建立数字档案，每次交易时先查档案，避免重复录入基本信息。对于大型项目，持久化缓存可以把二次构建时间从分钟级降到秒级，而且不会因为 node_modules 的微小变化导致全量失效——因为模块哈希只跟实际参与打包的代码有关，未改动的第三方库即使升级了小版本，只要源码未变，仍可能命中缓存。
值得注意的是，缓存记忆必须足够聪明才能避免带来副作用。Webpack 5 的缓存会记录 loader 的执行上下文，包括 loader 的版本、选项，甚至 this 上的文件系统访问信息。如果某个 loader 依赖了动态文件读取或环境变量，这些变化也会被记录并导致缓存失效，防止出现过时的编译结果。从「了解你的客户」角度看，这就像不仅知道客户的静态信息，还能感知到他在不同场景下的行为变化，从而提供更贴切的处理策略。
模块联邦：管理跨项目依赖这个「外部客户」
如果说持久化缓存是搞清楚自己项目内部的客户，那 Module Federation（模块联邦）就是帮你去了解、信任并协作管理外部的依赖客户。这也是 Webpack 5 最具想象力的新特性，它允许多个独立构建的应用在运行时共享模块，就像微前端架构的「依赖去中心化」方案。
模块联邦的核心是在一个应用的 Webpack 配置中声明 exposes（暴露出去的模块）和 remotes（要从远程加载的容器）。当应用 A 声明远程容器 B 时，它会告诉 Webpack：“有一些模块不是本地的，需要在运行时去 B 那里取”。此时，Webpack 构建时会为这些远程模块生成一个异步的加载脚本，但并不把它们打进本地包。这就像银行在为客户做 KYC 时，发现该客户的部分资产是托管在另一个金融机构的，那么就需要建立一套合规的共享机制，让两方能既安全又高效地交换信息。
一个典型的配置片段如下：
// app1 的 webpack.config.js
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'app1',
remotes: {
app2: 'app2@http://localhost:3002/remoteEntry.js',
},
shared: {
react: { singleton: true, eager: true },
'react-dom': { singleton: true, eager: true }
}
})
]
};
在这份配置里，shared 选项是整个 KYC 流程中最精妙的部分。它不仅声明了两边共享依赖，还可以通过 singleton: true 要求整个页面只存在一个 React 实例，即使版本不一致也要协商使用其中一个版本。Webpack 5 会根据 shared 中的版本范围、requiredVersion 以及 singleton 等约束，生成一套运行时协商逻辑。当远程模块加载时，首先检查宿主环境中是否已有可共享的模块，有则直接使用，没有则从自己的 fallback 中去加载。这种对共享依赖的严格管控，就像是 KYC 流程中对客户提供的资产证明进行多重验证：一方面避免重复加载造成浪费，另一方面防止不同版本的库混合导致难以排查的 bug。
从实践角度看，实施模块联邦之前，团队必须像做客户尽职调查一样梳理清楚：哪些依赖是真正可以共享的？如果远端挂了，本地有没有降级方案？那些不兼容的模块（例如带有副作用且不能重复执行的库）怎么处理？Webpack 5 没有替你回答这些，但它提供了足够透明的配置项和错误提示，比如当 remotes 加载失败时触发 webpack/container/fallback 机制，让你能监控到哪个「外部客户」出问题了。懂得用 KYC 思维去规划模块联邦，才能真正把微前端架构跑稳，而不是引入一堆运行时故障。
Webpack_5模块依赖分析Module_Federation修改时间：2026-08-12 20:54:56