Webpack 5 自发布以来，其核心变更并不只是版本号递进，而是把过去社区通过插件与临时方案解决的问题逐步内化到构建工具本身。对日常需要维护多包仓库或中型前端系统的团队来说，最直观的感受是配置文件变短了，但构建行为的可控性反而提高了。本文从模块联邦、持久化缓存与资源模块三个角度，拆解这些新特性如何重塑前端工程化链路。
模块联邦如何降低微前端协作成本
在 Webpack 5 之前，若想实现多个独立部署的前端应用之间共享组件或工具函数，通常要借助 npm 包抽离、运行时加载脚本或者自研加载器。这类方案要么带来版本碎片化，要么要求所有团队遵循严格的发布节奏。模块联邦（Module Federation）从构建期就定义了远程模块入口，使一个应用能像引用本地文件一样引用另一个应用暴露的模块，且不需要将依赖打进自身包体。
具体配置上，通过在 webpack.config.js 中声明 ModuleFederationPlugin，我们可以指定 name、remotes 与 exposes。下方示例展示了一个基础生产者暴露按钮组件，消费者远程引用的写法。注意远程地址应指向带 remoteEntry.js 的部署路径。
// 生产者 webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'appA',
filename: 'remoteEntry.js',
exposes: {
'./Button': './src/Button.js'
},
shared: ['react', 'react-dom']
})
]
};
// 消费者 webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'appB',
remotes: {
appA: 'appA@https://ipipp.com/remoteEntry.js'
},
shared: ['react', 'react-dom']
})
]
};
模块联邦的优势在于它把依赖调度推到了运行时，构建工具只负责生成符合协议的远程入口。但这也带来新的运维要求：远程地址必须稳定可用，否则本地构建虽然成功，页面运行却会白屏。相比传统的 npm 依赖，故障排查从编译阶段转移到了网络与部署阶段，团队需要配套的监控手段。
持久化缓存对构建速度的实质提升
Webpack 4 及更早版本主要依赖内存缓存，每次启动进程后首次构建都需重新遍历依赖图。Webpack 5 引入的持久化缓存可将模块处理结果写入文件系统，默认位于 node_modules/.cache/webpack。当源码与依赖未变化时，二次启动能跳过大量解析与编译步骤。
开启方式极为简单，只需在配置中设置 cache: { type: 'filesystem' }。以下片段展示最小启用方式，并可选择性指定缓存目录与版本标识，避免不同分支互相污染缓存。
module.exports = {
cache: {
type: 'filesystem',
cacheDirectory: require('path').resolve(__dirname, '.temp_cache'),
version: 'v1'
}
};
从实测角度看，含有上千模块的项目冷缓存构建可能耗时四十秒，热缓存可降至十秒以内。但需要注意，若频繁修改 babel 配置或loader版本，缓存命中率会下降。因此在 CI 环境中，建议将缓存目录挂载到持久卷，否则每次流水线都是冷启动，反而因写缓存增加少量开销。持久化缓存不是银弹，它要求团队的构建环境具备一定的状态连续性。
资源模块怎样替代传统 loader 链
过去处理图片、字体等静态资源，开发者必须在 rules 中组合 url-loader、file-loader 并设定 limit 阈值。Webpack 5 内置了资源模块类型，包括 asset/resource、asset/inline、asset/source 与 asset，用统一语法描述资源走向。
举例来说，将小于八千字节的图片转 base64，更大的输出文件，只需一条规则。这减少了依赖安装数量，也降低了配置理解成本。下列代码演示了用资源模块处理图片与文本。
module.exports = {
module: {
rules: [
{
test: /.(png|jpe?g|gif)$/i,
type: 'asset',
parser: {
dataUrlCondition: {
maxSize: 8 * 1024
}
}
},
{
test: /.svg$/,
type: 'asset/source'
}
]
}
};
资源模块的另一个好处是错误提示更贴近 Webpack 原生体系，不再因第三方 loader 版本不兼容而出现晦涩堆栈。不过对于需要复杂重命名或上传 CDN 的场景，仍要配合自定义插件在 emit 钩子中干预。总体来看，它把常见需求标准化，让初学者不必在 loader 文档中反复跳转，也减轻了升级时依赖冲突的概率。
新特性组合下的工程化取舍
当模块联邦、持久化缓存与资源模块同时启用，项目的构建架构会从“靠经验堆插件”转向“用核心能力搭骨架”。这种转变对十人以下前端团队尤其友好，因为维护自研构建脚本的人力被释放出来。但也要警惕全部特性开启后配置透明度降低，新人可能不清楚远程模块失败的根因在网络层。
建议的做法是先单独引入资源模块，观察构建体积与报错变化；再在需要多应用共享时启用模块联邦，并配套部署健康检查；最后在本地与 CI 分别验证持久化缓存收益。通过分阶段落地，既能享受 Webpack 5 的红利，也能把未知风险控制在可回溯范围内。工程化从来不是工具越新越好，而是与团队交付节奏相匹配才产生价值。