如果说 Webpack 4 时代还算是前端的和平年代，那么进入 Webpack 5 之后，构建工具领域俨然形成了一个竞争宇宙：Vite 凭借原生 ESM 和 esbuild 预构建拿下了新项目的半壁江山，Rollup 在组件库领域稳扎稳打，Parcel 继续主打零配置。面对这样的局面，Webpack 5 交出的答卷并不保守，它带来了持久化缓存、模块联邦、更好的 Tree Shaking 等一大批硬核特性。这篇文章就来逐一拆解这些特性，看看老牌霸主在这场竞争中的真实实力。
模块联邦：微前端的代码共享革命
模块联邦（Module Federation）可以说是 Webpack 5 最具话题性的特性，它解决的是一个长期困扰大型团队的问题：多个独立部署的应用之间，如何优雅地共享组件和依赖，而不是各自打包一份、或者强行塞进 monorepo 里。模块联邦允许一个应用在运行时动态加载另一个应用暴露出来的模块，宿主应用和远程应用可以共享同一份依赖实例，比如两个应用都依赖 React 18，通过配置 shared 就能保证页面上只存在一份 React。
下面是一个最小化的配置示例，宿主应用声明要消费的远程模块，远程应用声明自己要暴露什么：
const { ModuleFederationPlugin } = require('webpack').container;
// 远程应用（提供方）
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'remoteApp',
filename: 'remoteEntry.js',
exposes: {
'./Button': './src/components/Button.jsx',
},
shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
}),
],
};
// 宿主应用（消费方）
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'hostApp',
remotes: {
remoteApp: 'remoteApp@https://cdn.example-cdn.com/remoteEntry.js',
},
shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
}),
],
};这套机制的价值在微前端场景下尤为突出。传统方案要么用 iframe 做物理隔离导致通信困难，要么用 single-spa 之类的路由分发框架但依旧要处理依赖重复的问题。模块联邦提供了第三条路：构建期解耦、运行时集成。需要注意的是，shared 配置里建议对 React 这类有全局状态的库声明 singleton，否则两个不同版本的实例共存时会出现 hooks 报错这类诡异问题。此外，远程模块加载失败时的降级处理也必须在架构层面提前设计好。
持久化缓存：二次构建速度的数量级提升
Webpack 5 的文件系统缓存是另一个重量级改动。开启之后，首次构建会把模块、chunk、resolve 结果等信息序列化到 node_modules/.cache 目录，二次构建时直接复用这些缓存，增量场景下的提速非常明显。配置方式相当简单：
module.exports = {
cache: {
type: 'filesystem',
buildDependencies: {
// 配置文件变化时让缓存失效
config: [__filename],
},
cacheDirectory: 'node_modules/.cache/webpack',
},
};它的原理在于缓存粒度做到了模块级别。Webpack 4 的 cache: true 只缓存内存中的模块解析结果，进程退出即失效；而 Webpack 5 通过内容哈希将每个模块的处理结果落盘，配合内存映射和快照校验机制，能精确判断哪些文件真正变化了。在一个中大型项目上实测，冷启动构建可能需要两三分钟，而改动几个文件后的热增量构建往往能压缩到十秒以内。
使用时有两个坑值得注意。一是 buildDependencies 一定要把 webpack 配置文件、babel 配置文件加进去，否则改了配置但缓存不失效，会产出错误结果且极难排查。二是 CI 环境如果做了缓存目录的持久化，要注意多分支并行构建时缓存版本的一致性，建议在缓存 key 里带上 lockfile 的哈希值。
与 Vite 的竞争：两种思路的正面对决
Webpack 5 面对的最大挑战者无疑是 Vite。两者的差异本质上不在配置写法，而在架构理念。Webpack 无论怎么优化，开发阶段依然要走完整的打包流程，把所有模块变成 bundle 再启动服务；Vite 则是按需编译，启动时只做依赖预构建（交给 esbuild），业务源码在浏览器请求到某个模块时才通过原生 ESM 实时转换。这导致开发启动速度上 Vite 几乎是碾压级的。
但生产构建层面，Vite 底层用的还是 Rollup，而 Webpack 5 借助持久化缓存和更好的 Tree Shaking，产物质量和构建吞吐量并没有落后太多。真正的分水岭在生态和场景：老项目、复杂微前端架构、深度依赖 loader 插件体系的工程，Webpack 5 依旧是更稳妥的选择；而全新立项、追求开发体验的中小型项目，Vite 的上手成本和迭代节奏更有优势。选型时与其争论谁更先进，不如盘点团队现有资产的迁移成本。
从 Webpack 4 迁移到 Webpack 5 时，还有几个变化点要提前评估。第一，Webpack 5 移除了对 Node.js 核心模块的自动 polyfill，代码里如果直接引用了 process、path 这类模块，需要手动安装并配置 resolve.fallback，否则会直接报错。第二，部分老旧的 loader 和插件在 major 版本升级后不再兼容，升级前务必对照官方的迁移清单逐项检查。第三，Node.js 版本要求提升到了 10.13 以上，CI 环境也要同步更新。
总体来看，Webpack 5 在这场构建工具的竞争宇宙里并没有坐以待毙，模块联邦打开了微前端的新范式，持久化缓存补齐了性能短板。它和 Vite 的关系更像是分工而非替代，理解每个特性背后的设计动机，比纠结工具排名重要得多。