Webpack 5 发布已经有一段时间，但很多团队仍在观望是否要从 Webpack 4 升级。一个容易产生误导的说法是，有人在社区里用 Leading Universe（领导宇宙）来称呼 Webpack 5 的某个新能力，实际上官方文档里根本没有这个特性名称，它很可能只是对模块联邦（Module Federation）的夸张翻译。与其纠结这个模糊概念，不如直接看清楚 Webpack 5 真正改变了什么：缓存机制、资源处理方式、跨应用模块共享策略，以及升级时需要处理的兼容性问题。
一、持久化缓存：二次构建速度提升的关键
Webpack 4 的默认缓存只在内存里，构建结束后进程退出，下次冷启动仍要重新解析模块、生成依赖图，大型项目往往要几十秒甚至几分钟。Webpack 5 引入了真正的文件系统级缓存，配置 cache.type 为 filesystem 后，它会将模块编译结果、依赖图、SourceMap 等中间产物写入 node_modules/.cache/webpack 目录。二次构建时直接读取缓存，跳过大量重复工作，冷启动时间也能大幅缩短。这里需要说明，开发模式和生产模式都可以使用文件缓存，但在生产环境如果使用 CI 构建，要注意缓存目录是否被清理以及缓存键是否与依赖版本相关。
module.exports = {
cache: {
type: 'filesystem',
buildDependencies: {
config: [__filename],
},
},
};
文件缓存并不是万无一失，最常见的问题是改了配置文件但缓存没有失效，导致构建结果与预期不符。原因是默认的缓存键没有包含配置文件变化，需要手动声明 buildDependencies.config。上面的配置示例把当前配置文件加入缓存依赖，这样每次修改 webpack 配置时 Webpack 会自动让缓存失效。另一个常见问题是多个项目共享同一个缓存目录时出现串扰，可以通过 cache.name 或 cache.version 隔离。
从实际数据看，启用文件缓存后，二次构建的耗时可以下降到原来的 10% 到 20%。以中型 React 项目为例，首次构建 45 秒，第二次可能在 6 到 8 秒之间。不过这并不意味着持久化缓存对所有场景都有同样收益，如果项目使用了大量未标副作用的有状态模块，缓存策略可能需要结合 cache.type 的细粒度配置，否则可能出现旧模块被误复用的情况。因此建议在 CI 中把缓存目录设为流水线缓存，稳定后再作为默认配置。
二、资源模块：无需再为静态资源安装一堆 loader
在 Webpack 4 中，处理 png、jpg、svg、字体文件需要安装 file-loader、url-loader、raw-loader，并且要在 rules 中配置复杂选项。Webpack 5 把这些能力收编到内置 Asset Modules 中，提供了四种模块类型：asset/resource 对应原来的 file-loader，产出单独文件并返回 URL；asset/inline 对应 url-loader，把文件以 Data URI 内联；asset/source 对应 raw-loader，直接导出文件内容字符串；asset 则根据文件大小自动在 resource 和 inline 之间切换。
配置方式非常简洁。只需在 module.rules 中添加 type 字段，无需再引入额外的 loader。对于需要控制输出目录和内联阈值的项目，可以通过 generator.filename 和 parser.dataUrlCondition.maxSize 实现。代码示例展示了 png 直接输出到 images 目录，jpg 在小于 8KB 时使用 Data URI，超过后输出文件。这种内置实现还带来了性能提升，因为不再经过多个 loader 的交接过程，而是在 Webpack 内部统一处理，产物路径生成和哈希计算也更稳定。
module.exports = {
module: {
rules: [
{
test: /\.png$/,
type: 'asset/resource',
generator: {
filename: 'images/[name].[hash:8][ext]',
},
},
{
test: /\.jpg$/,
type: 'asset',
parser: {
dataUrlCondition: {
maxSize: 8 * 1024,
},
},
},
],
},
};
迁移时需要注意，旧项目中针对这些 loader 的 options 不能直接照搬。例如 url-loader 的 limit 选项对应到 asset 类型时是 parser.dataUrlCondition.maxSize；file-loader 的 outputPath 对应 generator.filename；raw-loader 的导出类型要改成 asset/source。这些差异虽然不大，但如果只是整体替换配置而不调整参数，很可能会出现资源路径错误或文件未内联的问题。
三、模块联邦：前端微服务的原生实现
模块联邦（Module Federation）可以说是 Webpack 5 最被高估也最有争议的特性。它允许运行在浏览器端的多个独立应用之间动态共享模块，而无需把所有代码打包进同一个仓库。一个典型的场景是：主应用 A 在运行时加载远程应用 B 暴露的组件，B 可以独立部署、独立升级，A 不需要重新构建。这在微前端架构中提供了一个比内嵌页面、Nginx 转发更灵活的方案，但复杂度也随之上升。
使用模块联邦需要在远程应用和宿主应用中分别配置 ModuleFederationPlugin。远程应用通过 exposes 暴露模块，并指定 filename 作为远程入口；宿主应用通过 remotes 声明远程地址。代码示例展示了一个宿主应用如何引用 app1 暴露的组件。需要注意的是，shared 字段用于声明两个应用共享的依赖，例如 React 和 ReactDOM，Webpack 会尽量保证共享依赖只实例化一次，避免出现多个 React 副本导致 Hook 报错。
// 远程应用 webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'app1',
filename: 'remoteEntry.js',
exposes: {
'./Button': './src/components/Button',
},
shared: ['react', 'react-dom'],
}),
],
};
// 宿主应用 webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'host',
remotes: {
app1: 'app1@http://localhost:3001/remoteEntry.js',
},
shared: ['react', 'react-dom'],
}),
],
};
尽管模块联邦看起来很美好，实际落地时仍有很多坑。远程模块的加载依赖网络请求，离线场景需要降级；远程应用的 CSS 不会自动提取注入，需要额外处理；共享依赖的版本不兼容时，Webpack 会回退到多个副本，但可能产生状态不一致的问题。此外，浏览器的异步加载队列、全局变量冲突、错误隔离等都需要手动设计。因此把模块联邦直接等同于“领导宇宙”级别的终极方案并不现实，它更适合已经具备微前端基础设施或者需要跨团队并行开发的场景。
四、升级前必须处理的兼容性问题
如果决定从 Webpack 4 升级到 5，第一个要确认的是 Node.js 版本。Webpack 5 要求 Node.js 10.13.0 以上，如果还在使用更低版本，需要先升级运行环境。其次，Webpack 4 在打包时自动注入 Node 核心模块的 polyfill，比如 Buffer、process、crypto，前端代码中如果直接使用这些全局变量，升级后会直接报错。Webpack 5 不再默认包含这些 polyfill，需要显式安装相应包并在 resolve.fallback 中声明。
module.exports = {
resolve: {
fallback: {
buffer: require.resolve('buffer/'),
process: require.resolve('process/browser'),
},
},
};
代码示例展示了 buffer 和 process 的 fallback 配置，实际项目中还需要根据报错信息逐个补充。注意 resolve.fallback 的值必须是模块路径，不能直接写包名。另一个容易踩坑的点是 output.jsonpFunction，多个 Webpack 构建同时存在时，如果都使用默认的 webpackJsonp 函数名，会互相覆盖。Webpack 5 用 output.uniqueName 来生成唯一命名空间，避免全局污染，但需要保证每个构建的 uniqueName 不重复。
还有几个行为变化值得关注：splitChunks 的默认配置更积极，小体积模块可能被合并得更彻底；target 默认值变为 browserslist，不再自动推断 Node 环境；IgnorePlugin、BannerPlugin 等插件参数也做了调整。升级时建议先用 Webpack 官方提供的迁移指南逐项检查，或者在测试环境完整跑一遍构建和运行时，再逐步推广到生产。
整体来看，Webpack 5 在构建速度、资源处理、微前端方面提供了实质性的提升，而不是某个模糊的“领导宇宙”概念。是否升级取决于项目规模和团队维护成本，建议从持久化缓存和资源模块开始尝试，模块联邦单独评估。升级时注意处理 polyfill 和配置兼容问题，才能平稳过渡。