把 Webpack 5 的一系列新特性组合起来看，就像一个琳琅满目的刷子宇宙：每一种刷子负责打磨构建流程中的一个环节，缓存刷子负责提速，联邦刷子负责跨应用共享模块，资源刷子负责处理图片字体。相比 Webpack 4，这一代版本不只是一个普通的升级，而是从内核架构上做了大量重构，移除了 Node.js 旧版本兼容代码、清理了废弃 API，同时引入了全新的持久化缓存、模块联邦和资源模块体系。如果你还在犹豫要不要从 Webpack 4 迁移到 Webpack 5，这篇文章会把这些核心刷子一支支拆开给你看。
持久化缓存：让二次构建快到飞起
Webpack 4 的缓存基本停留在内存层面，构建进程一结束缓存就随之消失，下次冷启动依然要老老实实从头解析每一个模块。Webpack 5 引入了基于文件系统的持久化缓存（Persistent Caching），它会把模块解析结果、依赖图、代码生成产物等中间状态序列化到磁盘上，下次构建时直接复用，只重新计算真正发生变化的部分。
开启方式非常简单，在配置中加上 cache: { type: 'filesystem' } 即可。下面是一个典型的开发环境配置示例：
const path = require('path');
module.exports = {
mode: 'development',
cache: {
type: 'filesystem',
buildDependencies: {
// 推荐把 webpack 配置文件本身加入依赖，配置变更后缓存自动失效
config: [__filename]
},
cacheDirectory: path.resolve(__dirname, '.webpack_cache'),
version: '1.0'
},
entry: './src/index.js',
output: {
path: path.resolve(__dirname, 'dist'),
filename: '[name].[contenthash].js'
}
};这段配置里有几个细节值得注意。buildDependencies 用来声明影响构建结果的额外依赖，比如 babel 配置、postcss 配置等，一旦这些文件内容变化，缓存会自动失效，避免拿到过期的产物。version 字段则用于手动控制缓存版本，当你怀疑缓存污染了构建结果时，改一下版本号就能强制全量重建。
在实际项目中，持久化缓存的效果非常明显。一个拥有上千个模块的中型项目，首次冷构建可能需要四五十秒，开启文件缓存后二次构建往往能压缩到几秒以内。官方设计目标是把增量重建的耗时控制在 500 毫秒以内，虽然真实场景不一定能达到，但提速幅度依然可观。需要注意的是，CI 环境中如果每次都是全新容器，磁盘缓存无法复用，可以考虑配合缓存目录的上传与还原策略来发挥它的价值。
Module Federation：跨应用共享模块的联邦刷
如果说持久化缓存解决的是速度问题，那么模块联邦（Module Federation）解决的就是架构问题。它允许多个独立构建、独立部署的应用在运行时互相暴露和消费模块，被消费的代码不会被重复打包，而是通过网络按需加载。这为微前端提供了一条开箱即用的路径，多个团队可以各自维护自己的应用，同时共享公共组件和工具库。
模块联邦涉及两个核心角色：提供方（remote）负责暴露模块，消费方（host）负责引用远程模块。下面先看提供方的配置：
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
module.exports = {
mode: 'production',
output: {
publicPath: 'https://cdn.ipipp.com/remote-app/'
},
plugins: [
new ModuleFederationPlugin({
name: 'remoteApp',
filename: 'remoteEntry.js',
exposes: {
// 对外暴露一个按钮组件
'./Button': './src/components/Button.js'
},
shared: {
// 与宿主共享 react，避免重复加载两份
react: { singleton: true },
'react-dom': { singleton: true }
}
})
]
};消费方一侧则通过 remotes 声明远程地址，之后在代码里就可以像导入本地模块一样导入远程组件：
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'hostApp',
remotes: {
remoteApp: 'remoteApp@https://cdn.ipipp.com/remote-app/remoteEntry.js'
},
shared: {
react: { singleton: true },
'react-dom': { singleton: true }
}
})
]
};
// 业务代码中的用法
// import RemoteButton from 'remoteApp/Button';shared 配置是模块联邦的精髓所在。它让多个应用之间协商依赖版本，singleton: true 表示全局只允许存在一个实例，这对 react 这类依赖单例上下文的库尤为重要，否则两个 React 副本会导致渲染异常。此外还可以配置版本范围和 requiredVersion，实现类似语义化版本的依赖协商。
模块联邦并非没有代价。它引入了运行时的异步加载逻辑，排查问题时链路变得更长；远程地址的可用性也直接关系到宿主应用的稳定性，生产环境通常需要配套降级方案。适合的场景是多团队并行开发的巨型平台、需要按需集成的插件化体系，而不适合简单的小项目，那只会徒增复杂度。
Asset Modules 与 Tree Shaking 升级
Webpack 5 把资源处理能力收进了内核，新增了四种资源模块类型：asset/resource 对应原来的 file-loader，负责输出独立文件；asset/inline 对应 url-loader，负责把资源转成 base64 内联；asset/source 对应 raw-loader，负责导出文件原始内容；asset 则是自动模式，可以根据文件大小在小图内联与大图独立输出之间自动切换。
module.exports = {
module: {
rules: [
{
test: /\.(png|jpe?g|gif|svg)$/i,
type: 'asset',
parser: {
dataUrlCondition: {
// 小于 8kb 的图片自动内联，超过则输出独立文件
maxSize: 8 * 1024
}
}
},
{
test: /\.txt$/,
type: 'asset/source'
}
]
}
};这意味着很多项目在迁移到 Webpack 5 之后，可以直接删掉 file-loader 和 url-loader 的依赖，配置更简洁，构建链路也更短。字体的处理同样适用 asset/resource 类型，配合输出模板中的 [hash][ext][query] 占位符可以精确控制产物命名。
另一个容易被忽视的改进是 Tree Shaking 能力的增强。Webpack 5 新支持了嵌套的 export 摇树优化、内部模块的 tree shaking，以及对 CommonJS 中部分符合模式的导出进行分析。配置 optimization.innerGraph: true 之后，编译器能够追踪模块内部变量之间的使用关系，把未被使用的赋值也一并剔除。再加上顶层的 sideEffects 字段配合，最终产物的体积往往能比 Webpack 4 小上一截。
迁移注意事项与总结
从 Webpack 4 升级到 Webpack 5，有几件事需要提前排查。首先是 Node.js 版本，Webpack 5 要求 Node 10.13 以上，实际生产中建议使用 LTS 版本。其次，所有引用了 webpack 内部 API 的插件和 loader 都需要升级到兼容版本，一些老旧插件可能已经停止维护，需要寻找替代品。另外，Webpack 5 移除了 polyfill 默认注入的行为，如果代码里直接使用了 process 或 node 核心模块，需要手动通过 resolve.fallback 配置替代方案。
回顾整个刷子宇宙：持久化缓存负责把构建速度拉起来，模块联邦负责把架构拆下去，资源模块负责把配置瘦身，Tree Shaking 增强负责把产物体积压下来。这四把刷子各自独立又相互配合，共同构成了 Webpack 5 的核心竞争力。如果你的项目还停留在 Webpack 4，建议先在一个分支上完成迁移验证，跑通构建与运行时回归测试后再合入主干，让这些新特性真正为你所用。
Webpack 5Module Federation持久化缓存修改时间：2026-09-13 05:46:32