Webpack 5 的发布让前端构建体系从单纯的打包工具向模块协调平台演进。所谓培养宇宙，可以理解为通过持久化缓存、模块联邦和资源模块等能力，把散落在不同仓库、不同团队之间的模块组织成一个可持续扩展的构建生态。接下来会从构建提速、应用协作和产物稳定性三个方向拆解这些特性的落地方法。
一、构建提速的核心：持久化缓存与依赖图复用
Webpack 4 时代，大多数项目使用的是 memory 缓存，进程退出后缓存消失。对于中大型项目，每次冷启动都要重新解析模块依赖图，严重拖慢开发反馈。Webpack 5 引入文件系统缓存（filesystem cache），允许将模块和 chunk 的编译结果序列化到磁盘，二次构建时直接复用这些中间产物。配置方式并不复杂，在 webpack.config.js 中设置 cache.type 为 filesystem 即可开启。
module.exports = {
cache: {
type: 'filesystem',
buildDependencies: {
config: [__filename],
},
},
};
上面的配置把配置文件本身也纳入缓存依赖，一旦配置文件发生变化，缓存自动失效。实际项目中，建议把 node_modules、测试环境变量等影响构建结果的内容也加入 buildDependencies，避免缓存的错误命中。根据社区和官方基准测试，文件系统缓存可以让二次构建时间减少 60% 到 90%，越是依赖复杂的项目收益越明显。
需要注意的是，文件系统缓存并非银弹。CI 环境中通常需要配置缓存目录的持久化，否则每次流水线重新拉取代码不会自动获得加速。此外，团队内如果升级了 Webpack 小版本或修改了 loader、插件版本，应主动清理缓存，避免使用过期产物导致难以排查的问题。
二、模块联邦：连接独立应用的运行时纽带
模块联邦（Module Federation）是 Webpack 5 最受关注的新特性之一，它让多个独立的构建产物在浏览器运行时动态共享模块，而不需要把这些模块提前打包进同一个 chunk。这种能力就像把若干个恒星系统连接成星系，每个应用可以暴露自己的组件或工具函数，也能消费其他应用暴露的模块。
要使用模块联邦，需要在 webpack.config.js 中引入 ModuleFederationPlugin。下面以一个远程应用暴露按钮组件为例：
const ModuleFederationPlugin = require('webpack').container.ModuleFederationPlugin;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'remoteApp',
filename: 'remoteEntry.js',
exposes: {
'./Button': './src/components/Button',
},
shared: ['react', 'react-dom'],
}),
],
};
在消费方，也就是宿主应用中，通过 remotes 字段声明远程入口，并像使用本地模块一样 import('remoteApp/Button') 即可。共享依赖通过 shared 配置控制版本匹配策略，可以显著减少重复加载，但也会引入版本协商的复杂度。实际落地时，建议先给共享依赖设置合理的版本范围，避免因为补丁版本不一致导致多个实例并存。
模块联邦适合微前端、公共组件库、以及多个团队并行交付大型中后台系统的场景。但它也带来了网络请求数量增加、加载失败兜底、样式隔离等问题，需要配套的错误边界和异步加载策略。整体上，模块联邦重新定义了构建产物之间的边界，让模块复用从编译期走向了运行时。
三、资源模块与内置能力：告别冗余 loader
Webpack 5 将资源处理从 loader 体系迁移到了内置的 asset modules。过去处理图片、字体、图标等文件通常需要 file-loader 或 url-loader，配置繁琐且版本兼容问题较多。现在通过 type: 'asset/resource' 可以直接输出文件，type: 'asset/inline' 可以把资源转为 base64 内联到代码中。
module.exports = {
module: {
rules: [
{
test: /\.png$/,
type: 'asset/resource',
},
{
test: /\.svg$/,
type: 'asset/inline',
},
{
test: /\.txt$/,
type: 'asset/source',
},
],
},
};
上面的规则把 PNG 图片作为单独文件输出，SVG 图标直接内联为 data URI，文本文件以源代码字符串形式导入。对于介于两者之间的场景，还可以使用 type: 'asset' 配合 parser.dataUrlCondition.maxSize 设置阈值，让 Webpack 自动决定内联还是输出文件。这种内置化设计减少了外部 loader 的依赖，也让配置更直观。
除了资源模块，Webpack 5 还移除了大量面向 Node.js 的自动 polyfill。Webpack 4 中，如果代码引用了 process 或 Buffer，Webpack 会尝试自动注入 polyfill。Webpack 5 不再默认提供这些 polyfill，需要时必须在 resolve.fallback 中显式声明。这一变化减少了浏览器产物的多余代码，但也要求开发者检查第三方库是否存在对 Node 全局对象的隐性依赖。
四、长期缓存与 tree shaking：让构建产物稳定可预测
长期缓存是前端性能优化的重要手段，目标是让未变更的文件保持稳定的 hash，变更时只更新必要资源。Webpack 5 对 moduleIds 和 chunkIds 的默认生成方式进行了优化，默认使用确定性的数字 ID，而不是依赖模块路径或顺序。这样在新增或删除模块时，不会导致大量文件的 hash 同时变化，从而提升浏览器缓存命中率。
开启长期缓存通常需要结合 contenthash 命名和 optimization.moduleIds、optimization.chunkIds 配置。示例如下：
module.exports = {
output: {
filename: '[name].[contenthash].js',
},
optimization: {
moduleIds: 'deterministic',
chunkIds: 'deterministic',
usedExports: true,
},
};
moduleIds: 'deterministic' 会根据模块内容生成稳定的小数字 ID，chunkIds: 'deterministic' 对 chunk 做同样处理。usedExports: true 配合 sideEffects 标记可以更彻底地移除未使用的导出。再结合 optimization.splitChunks 的合理分组，可以把公共依赖稳定地拆成独立 chunk，进一步减少重复下载。
需要注意的是，要让 tree shaking 发挥最大效果，业务代码和第三方库都需要正确声明 sideEffects。在 package.json 中设置为 false 表示所有模块都无副作用，可以安全删除未引用代码；如果有样式文件等副作用资源，需要将其列入数组排除。这些细节会直接影响最终产物的体积和缓存稳定性。
Webpack 5 的培养宇宙不是某个单独的功能，而是一组相互配合的能力。持久化缓存降低迭代成本，模块联邦扩展协作边界，资源模块和长期缓存让产物更轻更稳定。掌握这些特性后，前端工程可以更从容地应对大型项目的复杂度。
Webpack 5新特性模块联邦持久化缓存修改时间：2026-09-20 01:58:13