Webpack 5 发布至今已经积累了大量生产环境的验证，相比 Webpack 4，它不是简单的小版本迭代，而是一次包含持久化缓存、模块联邦、资源模块在内的架构级重构。很多团队在升级后最直观的感受是构建时间大幅缩短，但如果只停留在跑通项目的层面，就会错过这些新特性真正能带来的工程收益。本文将从几个核心特性入手，逐个分析它们解决了什么问题，以及在实际项目中如何用好它们。
持久化缓存：让二次构建快到没有感知
Webpack 4 时代的缓存只能存在于内存中，每次重启构建进程，所有模块都要重新解析、重新编译。对于中大型项目来说，一次完整的冷启动构建动辄几分钟，开发体验非常糟糕。Webpack 5 引入了基于文件系统的持久化缓存，它会把模块的解析结果、编译产物、resolve 过程等全部序列化到磁盘上，下次启动时直接反序列化恢复，跳过大量重复工作。
开启方式非常简单，在配置中加一行即可：
module.exports = {
cache: {
type: 'filesystem',
buildDependencies: {
// 推荐把配置文件本身加入依赖，改配置后缓存自动失效
config: [__filename]
}
}
};这里有几个细节需要注意。首先是buildDependencies，它声明了哪些文件变更时应该让缓存整体失效。如果把 webpack 配置文件加进去，修改配置后不会误用旧缓存。其次，缓存对 CI 环境同样有价值，可以把.cache目录缓存到 CI 的产物缓存中，流水线的增量构建速度会有质的飞跃。最后要留意 node_modules 依赖升级的情况，Webpack 会通过解析版本和文件时间戳判断是否失效，但如果遇到诡异的缓存问题，删掉node_modules/.cache目录重试是最直接的排查手段。
实测下来，一个包含上千个模块的项目，冷构建需要一分钟左右，而命中缓存后的增量构建通常能压缩到几秒以内。这个差距在多人协作、频繁切换分支的场景下尤为明显。
模块联邦：跨应用共享代码的官方方案
模块联邦（Module Federation）可以说是 Webpack 5 最具原创性的功能。它允许一个 JavaScript 应用在运行时动态加载另一个独立构建的应用中的模块，并且双方可以共享依赖，避免同一个库被打包两份。这直接解决了微前端架构下最头疼的问题：子应用之间如何优雅地复用组件和工具库。
看一个最小可用的例子。先定义提供方应用：
// app1/webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'app1',
filename: 'remoteEntry.js',
exposes: {
// 对外暴露 Button 组件
'./Button': './src/components/Button'
},
shared: {
react: { singleton: true },
'react-dom': { singleton: true }
}
})
]
};然后在消费方应用中引用它：
// app2/webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'app2',
remotes: {
// 远程应用的地址，运行时动态拉取 remoteEntry.js
app1: 'app1@http://localhost:3001/remoteEntry.js'
},
shared: {
react: { singleton: true },
'react-dom': { singleton: true }
}
})
]
};在 app2 的业务代码里，可以直接像本地模块一样导入远程组件：
const RemoteButton = React.lazy(() => import('app1/Button'));
function App() {
return (
<Suspense fallback={"加载中"}>
<RemoteButton />
</Suspense>
);
}shared配置里的singleton: true很关键，它保证 React 这类有全局状态要求的库只会实例化一次，否则消费方和提供方各自持有不同版本的 React 实例，会导致报错。版本协商机制也值得了解：双方共享的依赖会对比版本号，优先使用较高版本，只要语义化版本兼容就只加载一份。这种设计让独立部署、独立构建的多个前端应用之间可以做到真正的按需共享，而不是简单地外部化一个 CDN 链接。
资源模块与 Tree Shaking 增强
Webpack 5 废弃了file-loader、url-loader和raw-loader，用原生的资源模块类型替代。现在只需要在module.rules里声明type: 'asset'系列即可，语法更统一，也不再需要额外安装 loader：
module.exports = {
module: {
rules: [
{
test: /\.png$/,
type: 'asset',
// 小于 8kb 的图片内联为 base64，超过则输出单独文件
parser: {
dataUrlCondition: { maxSize: 8 * 1024 }
}
},
{
test: /\.txt$/,
type: 'asset/source' // 等价于原来的 raw-loader
}
]
}
};四种资源类型各有分工：asset/resource输出文件并返回 URL，asset/inline转成 data URI，asset/source返回源文件内容，asset则根据大小在前两者之间自动选择。相比旧的 loader 方案，原生实现的解析速度更快，配置心智负担也更小。
Tree Shaking 方面，Webpack 5 引入了嵌套的无用代码消除和更好的模块内部分析能力。最实用的一点是支持对 CommonJS 导出做部分静态分析，同时新增了sideEffects配合下的深层优化：当一个模块的所有导出都未被使用，且该模块声明了无副作用，整棵子树都会被剪掉。对于组件库和工具库的作者来说，合理声明package.json中的sideEffects: false（或按文件排除 CSS 等副作用文件），能让业务方的产物体积显著下降。
迁移过程中的注意事项
从 Webpack 4 升级到 Webpack 5，大部分问题集中在几个方面。第一，Node.js 版本要求提升到了 10.13 以上，老项目的 CI 环境需要同步升级。第二，不再自动注入 Node.js 的核心模块 polyfill，如果代码里引用了process、path等模块，需要在resolve.fallback中手动指定，或者直接改造代码去掉这些依赖。
第三，webpack-dev-server的命令行参数有较大调整，热更新配置迁移到devServer对象中，老的 CLI 写法不再可用。第四，部分插件的兼容性需要确认，比如copy-webpack-plugin、html-webpack-plugin都要求升级到支持 Webpack 5 的大版本。建议的做法是先在分支上升级，逐个处理编译报错，再借助stats.json分析产物体积变化，确认 Tree Shaking 和缓存都按预期工作。
总的来说，Webpack 5 的这些新特性不是零散的功能堆砌，而是围绕构建性能和应用架构两条主线做的系统性重构。持久化缓存解决构建速度问题，模块联邦解决代码共享问题，资源模块简化配置，Tree Shaking 增强减小产物体积。把这些特性用好，前端工程化的基础设施会上一个台阶。