在 Webpack 5 发布之后，社区里讨论最多的往往是持久化缓存有多快、模块联邦有多神奇，但真正决定一次升级是否值得的，其实是背后那些明确的需求动机。所谓 Want 需求，指的是团队在工程实践中明确提出的目标诉求，例如构建速度要快、多个应用之间要共享依赖、产物体积要更小等。Webpack 5 的几乎每一项新特性，都是围绕这类需求展开的。理解了需求本身，再看配置就会顺畅很多，也不容易陷入为了升级而升级的误区。
什么是 Want 需求，它和 Webpack 5 的关系是什么
Want 需求并不是 Webpack 配置文件里的某个字段，而是一种工程决策视角。换句话说，它是在问你：你的项目到底想要什么？是想要把冷启动构建从十分钟压到一分钟，还是想让多个微前端应用共享一份 React 运行时，或者是想在产物里彻底剔除那些没有用到的导出？每一种 Want 对应到 Webpack 5 中，都有一整套特性来支撑。
这种思维方式的价值在于，它能帮你避免两个常见的坑。第一个坑是无脑升级，团队看到新版本发布就立刻跟进，结果项目本身规模很小，构建本来就只要十几秒，升级带来的收益几乎感知不到，反而要承担插件不兼容的风险。第二个坑是配置堆砌，把官方文档里看到的所有优化选项一股脑抄进配置文件，比如同时开启了不合适的缓存策略和代码分割策略，最终产物体积不降反升。
正确的做法是先列出诉求清单，再逐条映射到 Webpack 5 的能力上。下面的表格给出了一个常见的对应关系：
| Want 需求 | 对应特性 | 典型收益 |
|---|---|---|
| 构建太慢，想要提速 | 文件系统持久化缓存 | 二次构建速度提升 60% 到 90% |
| 多应用想共享依赖 | Module Federation 模块联邦 | 避免重复打包公共库 |
| 产物体积过大 | 更精细的 Tree Shaking 与嵌套摇树 | 无用代码剔除更彻底 |
| 告别 polyfill 膨胀 | 移除自动 Node.js polyfill | 面向浏览器的产物更干净 |
从提速需求出发：持久化缓存的配置与实践
构建速度是大多数团队升级 Webpack 5 时排在第一位的 Want。Webpack 4 时代虽然有 cache-loader 和硬磁盘缓存方案，但都属于外部补丁，覆盖面和稳定性都不理想。Webpack 5 把缓存直接内置到了核心流程中，通过 cache.type: 'filesystem' 开启基于文件系统的持久化缓存，首次构建时会把模块解析结果、依赖图等关键信息写入磁盘，后续构建直接复用，未变化的模块甚至不会被重新编译。
基础配置非常简单，只需要在配置对象中加几行：
// webpack.config.js
module.exports = {
cache: {
type: 'filesystem',
// 建议显式声明构建依赖，配置文件变化时缓存自动失效
buildDependencies: {
config: [__filename]
},
// 缓存写入目录，默认是 node_modules/.cache/webpack
cacheDirectory: path.resolve(__dirname, '.temp_cache')
}
};
这里有一个容易被忽视的细节：buildDependencies 的作用。如果配置文件、babel 配置等发生了变化，而缓存没有失效，就会出现改了配置但产物没变化的诡异问题，很多团队排查半天最后发现是缓存惹的祸。把相关配置文件的路径都声明进去，Webpack 会在这些文件变化时自动让缓存失效，这是生产环境必做的操作。
另外一个实践建议是在持续集成环境中谨慎使用持久化缓存。CI 机器往往是全新环境，缓存目录不存在，写缓存反而会增加构建时间。可以配合环境变量判断，只在本地开发时开启，或者在 CI 上配合缓存策略把缓存目录也存起来复用。
从共享需求出发：模块联邦解决依赖重复问题
当团队里存在多个独立部署的前端应用时，一个典型的 Want 就是共享依赖。比如主应用和子应用都依赖 React，如果各自打包，用户浏览器里会同时存在两份 React 运行时，体积和内存都翻倍。Webpack 5 的 Module Federation 模块联邦就是针对这个需求设计的，它允许一个应用在运行时动态加载另一个应用暴露出来的模块，并且可以共享公共依赖。
// 子应用 remote 的 webpack 配置
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 }
}
})
]
};
配置里的 shared 字段是关键，声明了 singleton: true 之后，浏览器里只会保留一份 React 实例，主应用和子应用共用。需要注意的是，共享依赖的版本协商有前提：如果主应用和子应用的 React 大版本不一致，运行时可能会降级加载其中一份，甚至出现不可预期的行为，所以使用模块联邦的团队最好统一依赖版本规范。
模块联邦并不意味着一定要上微前端架构。即使是单体内的多页面项目，也可以用它把公共组件库做成远程模块，实现组件热更新而不需要每个页面重新发版。从 Want 出发评估：如果多个构建产物之间存在明显的重复依赖，模块联邦就值得投入；如果只有一个单体应用，引入它只会徒增复杂度。
从体积需求出发：Tree Shaking 与 polyfill 的取舍
产物体积相关的 Want 在 Webpack 5 里得到了两层回应。第一层是嵌套的 Tree Shaking，Webpack 4 只能摇掉模块顶层的未使用导出，而 Webpack 5 可以分析嵌套在对象内部、甚至经过 re-export 的未使用属性，像 lodash 这类工具库的剔除效果明显更好。配合 sideEffects 字段声明，效果还能进一步提升：
{
"name": "my-ui-lib",
"version": "1.0.0",
"sideEffects": false
}
第二层是移除了对 Node.js 核心模块的自动 polyfill。Webpack 4 会在引用 process、path 等模块时自动注入 polyfill，这对纯浏览器项目来说是无意义的体积负担。Webpack 5 直接砍掉了这个行为，遇到此类引用会抛出错误提示。如果你的代码或者第三方依赖确实需要这些能力，就要显式安装对应的 polyfill 并通过 resolve.fallback 配置，这虽然是升级时的一个迁移成本，但换来的产物更干净、依赖关系更透明。
升级时建议先跑一次完整构建，观察报错信息里列出的缺失模块清单，再逐个决定是补 polyfill 还是改写代码。直接把所有 fallback 配置成 false 可以快速通过构建，但要确认没有运行时依赖这些 API 的代码路径，否则会在用户浏览器里抛出运行时错误，这类问题比构建报错更难排查。
如何判断你的项目是否需要升级
回到最初的 Want 需求视角，升级决策可以总结为三个问题：构建时间是否已经成为团队的开发效率瓶颈？是否存在多应用共享依赖的明确诉求？产物体积是否大到影响用户体验？只要其中一个问题的答案是肯定的，升级 Webpack 5 就有明确的收益支撑。
如果三个问题的答案都是否定的，那么可以暂缓升级，把精力放在业务上。同时要注意升级前的兼容性检查：确认项目中使用的 loader 和插件是否已经发布了兼容 Webpack 5 的版本，尤其是 copy-webpack-plugin、html-webpack-plugin 这类常用插件的版本匹配问题。Node.js 版本也建议使用较新的 LTS 版本，Webpack 5 官方要求至少 Node 10.13，但实际生产中建议使用更高版本以获得更好的性能表现。
最后，无论出于哪种需求升级，都建议在新分支上完成迁移并跑完整的回归测试，重点验证持久化缓存开启后的增量构建正确性，以及模块联邦场景下共享依赖的版本协商结果。构建工具的升级从来不是目的，满足团队真实的 Want 需求、让开发体验和线上体验同时受益，才是这场升级的终点。