Webpack 5 是这个构建工具近年来最重磅的一次大版本更新，官方团队花了两年多时间打磨，从性能、体积到架构能力都做了系统性重构。其中最引人注目的三个能力是模块联邦、持久化缓存和增强版 Tree Shaking，它们分别解决了微前端模块共享、二次构建慢、产物体积大这三个长期困扰前端工程的问题。本文将逐一拆解这些特性的底层原理，并给出可以直接使用的配置示例，帮助你判断自己的项目是否值得升级、如何平滑升级。
模块联邦：微前端的官方级解决方案
模块联邦（Module Federation）是 Webpack 5 中最具想象力的特性，它允许多个独立构建、独立部署的应用在运行时互相共享模块。简单来说，A 应用可以动态加载 B 应用暴露出来的某个组件或工具函数，而这两个应用在构建阶段完全不知道对方的存在。
在模块联邦出现之前，实现类似能力通常要依赖 externals 加 CDN 脚本，或者自己搭一套运行时加载器，维护成本高且缺乏类型支持。模块联邦把这套机制内置到了打包器层面，宿主应用（Host）和远程应用（Remote）通过一个共享的契约文件通信，公共依赖（比如 React）还可以配置成单例，避免多个应用各自打包一份框架代码导致页面里出现多个 React 实例的问题。
下面是一个远程应用暴露组件的典型配置：
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'remoteApp',
filename: 'remoteEntry.js',
exposes: {
// 对外暴露一个按钮组件，宿主可以通过 remoteApp/Button 引用
'./Button': './src/components/Button.js',
},
shared: {
// React 配置为单例，所有使用方共享同一个运行时实例
react: { singleton: true, requiredVersion: '^18.0.0' },
'react-dom': { singleton: true },
},
}),
],
};
宿主应用只需在配置中声明 remotes 字段，指向远程应用的 remoteEntry.js 文件，就可以像引用本地模块一样引用远程组件。需要注意的是，shared 依赖的版本协商发生在运行时，如果宿主和远程的版本差异过大，可能会触发重复加载或警告，建议在团队内约定好共享依赖的版本范围。
持久化缓存：让二次构建进入秒级时代
Webpack 5 移除了原本的 cache: { cacheDirectory } 写法，引入了全新的文件系统缓存机制。开启之后，第一次构建会把模块、解析结果、插件中间产物等序列化到磁盘上的 node_modules/.cache/webpack 目录，第二次构建时直接复用这些缓存，只重新处理真正变化的文件。
这套机制对大型项目的收益非常明显。一个原本需要三四十秒的全量构建，开启持久化缓存后通常能压缩到几秒甚至一秒以内。更重要的是，缓存是基于内容哈希的，即使你切换分支或者改了配置文件中的部分内容，未受影响的模块依然可以命中缓存。
基础配置非常简单：
module.exports = {
cache: {
type: 'filesystem',
buildDependencies: {
// 配置文件本身变化时，自动使缓存失效
config: [__filename],
},
cacheDirectory: path.resolve(__dirname, '.temp_cache'),
},
};
buildDependencies 是容易被忽视的关键项。默认情况下 webpack.config.js 的变更不会让缓存失效，可能导致改了配置却看不到效果，把配置文件路径加进去可以避免这类诡异问题。另外，在 CI 环境中使用持久化缓存时，要确认缓存目录被正确保存和恢复，否则每次流水线都是冷启动，收益归零。
更彻底的 Tree Shaking 与全新的资源模块
Webpack 5 的 Tree Shaking 能力有了实质性增强。它现在可以分析嵌套的 export 结构，也就是说 export * from './utils' 这种链式导出中的无用代码也能被摇掉。同时，新增了对 CommonJS 的部分分析支持，能够处理 exports.xxx = ... 这种简单形式的赋值导出，虽然复杂场景仍不支持，但已经能覆盖不少老包的优化需求。
另一个实用改进是嵌套的无用模块消除。配合 sideEffects: false 的 package.json 声明，整个没有副作用的目录都可以被安全剔除。建议在自己的库项目中显式声明 sideEffects 字段，这直接决定了使用方的打包体积。
资源处理方面，Webpack 5 引入了 Asset Modules，用内置的 asset/resource、asset/inline、asset/source 和 asset 四种类型替代了 file-loader、url-loader 和 raw-loader。配置上从一堆 loader 变成了简洁的类型声明：
module.exports = {
module: {
rules: [
{
// 图片字体等资源直接用内置类型处理，不再需要 file-loader
test: /\.(png|jpg|gif|svg|woff2)$/,
type: 'asset',
parser: {
dataUrlCondition: {
// 小于 8kb 的资源内联为 base64，超过则生成独立文件
maxSize: 8 * 1024,
},
},
},
],
},
};
type 设为 asset 时会根据文件大小自动在资源文件和 base64 内联之间做选择，阈值通过 dataUrlCondition 控制。迁移老项目时，记得移除对应的 loader 依赖并删除 rules 中的旧配置，否则内置类型和 loader 可能产生冲突。
升级注意事项与总结
升级 Webpack 5 之前有几件事需要确认。第一，Node.js 版本必须不低于 10.13，官方推荐使用 LTS 版本。第二，检查项目依赖的插件是否兼容，部分老插件（尤其是深度依赖内部 API 的）需要升级到支持 v5 的版本。第三，Webpack 5 移除了自动 Node.js polyfill 的行为，如果前端代码里引用了 path、crypto 等 Node 内置模块，需要手动安装对应的 polyfill 并通过 resolve.fallback 配置，否则构建会直接报错。
整体来看，Webpack 5 的升级收益排序大致是：持久化缓存带来的开发体验提升最直观，模块联邦为微前端架构提供了标准化方案，Tree Shaking 和 Asset Modules 则在产物体积和配置简洁度上持续输出价值。对于仍在 Webpack 4 上的项目，如果构建时间已经成为团队效率的瓶颈，或者正计划拆分微前端，这次升级值得尽早排期。迁移过程中建议开启 stats: 'errors-warnings' 详细观察弃用警告，分阶段推进，先在分支上验证核心构建链路，再逐步覆盖到开发、测试和生产的完整流程。
Webpack 5Module Federation持久化缓存修改时间：2026-09-01 00:52:35