Webpack 5 发布后，很多人把关注点放在升级适配和配置迁移上，却忽略了它真正能改变构建体验的一系列底层能力。所谓 Peak Universe 山峰宇宙，并不是官方文档里出现的某个独立选项，而是对 Webpack 5 中持久化缓存、资源模块、模块联邦和更严格树摇优化等特性组合的一种形象比喻。它描述的是一种理想状态：依赖关系像宇宙中的山峰一样清晰有序，构建过程不再被冗余计算拖累，跨应用模块共享像星际航道一样顺畅。要登顶这片山峰宇宙，需要分别理解每个特性的工作原理和适用场景。
下面就从几个核心维度拆解这些特性，看看它们如何帮助前端工程接近构建性能的巅峰。
持久化缓存：构建速度的山峰底座
Webpack 5 内置了文件系统级别的持久化缓存，这是提升二次构建速度最直接的手段。旧版本中，每次重新打包都需要从入口开始重新解析所有模块，即使源码没有变化，重复的编译和依赖分析也会消耗大量时间。Webpack 5 通过把模块编译结果、依赖关系图以及代码生成阶段的中间产物写入磁盘缓存，在后续构建时跳过没有变化的模块，大幅缩短构建时间。
要启用持久化缓存，只需要在配置中加入 cache 字段并指定类型为 filesystem。示例如下：
// webpack.config.js
const path = require('path');
module.exports = {
cache: {
type: 'filesystem',
buildDependencies: {
config: [__filename]
},
cacheDirectory: path.resolve(__dirname, '.webpack_cache')
},
entry: './src/index.js',
output: {
path: path.resolve(__dirname, 'dist'),
filename: '[name].[contenthash].js'
}
};
这里要注意几个容易踩坑的细节。buildDependencies 用来声明哪些配置文件变化时需要重新构建缓存，如果不把 webpack.config.js 自身加入进去，修改配置后旧缓存可能仍然生效，导致奇怪的行为。cacheDirectory 最好指定项目内的固定目录，方便 CI 环境复用或清理。此外，缓存对 node_modules 的依赖变化也很敏感，升级依赖后建议手动删除缓存目录，避免版本错乱带来的诡异报错。
持久化缓存的效果在小项目中可能不明显，但在包含数百个模块的大型应用中，二次构建时间通常可以从几十秒下降到几秒。这也是实现 Peak Universe 山峰宇宙体验的第一步：先让重复构建的成本降到最低，后续的模块优化才有更明显的收益。
资源模块与更严格 Tree Shaking：清理依赖宇宙中的碎石
Webpack 5 把 raw-loader、file-loader、url-loader 等资源加载器统一成了内置的资源模块机制，根据配置自动选择导出 URL、文件内容或 Base64 数据。这简化了配置，也减少了额外 loader 带来的解析开销。例如处理图片资源时，不再需要安装多个 loader，只需使用 type: 'asset' 并设置大小阈值。
module.exports = {
module: {
rules: [
{
test: /\.png$/,
type: 'asset',
parser: {
dataUrlCondition: {
maxSize: 8 * 1024
}
}
}
]
}
};
与资源模块同样重要的是 Tree Shaking 的增强。Webpack 5 对未使用代码的消除更加彻底，尤其是在嵌套依赖、CommonJS 混合使用以及 sideEffects 标记方面。sideEffects 字段允许包作者声明哪些文件包含副作用，从而让打包器放心地移除未引用的模块。在项目中，合理设置 package.json 的 sideEffects 为 false 或数组，能显著减少输出体积。
但这里有一个常见的误区：如果项目中的 CSS 文件通过 import 方式引入，而 sideEffects 被粗暴地设置为 false，就可能导致样式被错误移除。正确做法是把样式文件排除在 sideEffects 之外，或者使用 Webpack 的规则显式处理。只有清理掉依赖宇宙中的无用碎石，输出结果才能瘦身并减少浏览器解析负担。
模块联邦：连接多个应用的宇宙桥梁
模块联邦是 Webpack 5 最具突破性的特性之一，它允许多个独立构建的应用程序在运行时共享模块，而不需要把它们打包成同一个代码库。这为微前端架构、插件化系统以及跨团队协作提供了原生支持。其核心思想是每个应用可以暴露自己的部分模块，同时也可以消费其他应用暴露的模块，形成一种动态的模块共享网络。
配置模块联邦需要使用 ModuleFederationPlugin，下面是一个简单的远程应用和宿主应用示例。远程应用暴露一个组件：
// 远程应用 webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'remoteApp',
filename: 'remoteEntry.js',
exposes: {
'./Button': './src/components/Button'
},
shared: ['react', 'react-dom']
})
]
};
宿主应用则声明需要消费的远程模块：
// 宿主应用 webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'hostApp',
remotes: {
remoteApp: 'remoteApp@http://localhost:3001/remoteEntry.js'
},
shared: ['react', 'react-dom']
})
]
};
模块联邦的优势在于部署独立性，远程应用可以单独发布，宿主应用无需重新构建即可获取更新后的模块。但这也带来版本管理和运行时故障处理的新挑战。shared 配置需要谨慎设计，避免同一个库被多个版本重复加载。实际使用中，建议结合单例模式和版本协商，确保 React 这类依赖只初始化一次。模块联邦就像连接不同山峰之间的桥梁，让整个前端宇宙中的模块可以按需流动。
其他不可忽视的峰顶能力
除了上述三大特性，Webpack 5 还在代码生成、模块解析和输出稳定性方面做了不少改进。例如 Top Level Await 的支持让异步初始化逻辑可以写在模块顶层，配合动态导入能够简化复杂场景下的代码组织。输出文件的 contenthash 计算也更加稳定，模块内容不变时 hash 不会变化，有利于浏览器长期缓存。
另一个值得关注的是更严格的模块解析规则。Webpack 5 默认不再自动填充 Node.js 核心模块的 polyfill，例如在浏览器代码中直接 require('crypto') 会报错。这迫使开发者显式声明依赖，避免无意义的 polyfill 增加包体积。虽然短期内会给迁移带来一些摩擦，但长远来看有助于保持依赖宇宙的纯净。
登顶 Peak Universe 山峰宇宙并不意味着一次性启用所有新特性，而是根据项目实际需求逐步引入持久化缓存、资源模块、模块联邦和更严格的树摇。每一步优化都能带来可感知的构建速度提升或产物体积下降，最终让前端工程从笨重的构建过程中解放出来，把更多时间留给真正的业务开发。