Webpack 5 自发布以来，官方和社区经常用 Ambition 来形容这代版本的设计取向。这个雄心并不是某个新增的独立 API，而是贯穿于模块加载、构建缓存和 Tree Shaking 等多个层面的系统性升级。以下从模块联邦、持久化缓存、产物优化与迁移策略四个角度展开。
模块联邦：让多个应用共享代码成为一等公民
在 Webpack 5 之前，多个独立构建的前端应用如果想复用一段业务组件，通常只能通过发布 npm 包、使用 iframe 嵌入或维护公共依赖的 external 配置。这些方案在独立部署、版本同步和运行时通信上都有明显摩擦。模块联邦把直接从一个构建产物中加载另一个构建产物的模块做成了官方能力，这正是 Webpack 5 最具有野心的设计之一。
模块联邦的核心是 ModuleFederationPlugin。它允许一个应用暴露自身的一部分模块，也允许另一个应用在运行时声明消费这些远端模块。下面是一个简单的 remote 端配置示例。
// webpack.config.js - remote 应用
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
// ...
plugins: [
new ModuleFederationPlugin({
name: 'remoteApp',
filename: 'remoteEntry.js',
exposes: {
'./Button': './src/components/Button',
},
shared: {
react: { singleton: true, requiredVersion: '^18.0.0' },
'react-dom': { singleton: true, requiredVersion: '^18.0.0' },
},
}),
],
};
host 应用则通过 remotes 字段声明远端入口地址。当构建完成并部署后，host 应用可以在运行时拉取 remoteApp 暴露出来的 Button 模块，而不需要把 Button 的源码提前安装到 host 的 node_modules 中。这种模式下，公共依赖 React 通过 shared 声明为单例，避免多个 React 副本导致的状态不一致问题。
模块联邦的价值不仅在于复用代码，更在于它改变了部署边界。不同团队可以独立发布自己的应用，只要保持远端入口地址和共享依赖版本契约稳定，就不会互相阻塞。对于大型微前端项目，模块联邦比传统的 iframe 或 npm 包发布更贴近运行时组合的真实需求。不过它也带来新的复杂度，例如远端模块加载失败时的降级方案、共享依赖版本冲突排查、以及入口文件的缓存策略都需要提前设计。
持久化缓存：构建速度从内存缓存走向磁盘缓存
Webpack 4 的缓存主要依赖 loader 缓存和部分内置的内存缓存。每次冷启动构建时，很多已经处理过的模块仍需重新转换、解析和打包。对于中型以上工程，二次构建时间往往要几十秒甚至更长。Webpack 5 引入的 filesystem cache 将缓存的中间结果写入磁盘，从根本上改变了这一局面。
开启文件系统缓存非常简单，在配置文件中加入 cache 字段即可。
// webpack.config.js
const path = require('path');
module.exports = {
cache: {
type: 'filesystem',
cacheDirectory: path.resolve(__dirname, '.webpack_cache'),
buildDependencies: {
config: [__filename],
},
},
// ...
};
这里的 buildDependencies 用来声明会影响构建结果的配置文件。当配置文件变化时，Webpack 会自动让旧缓存失效，避免因为缓存陈旧导致错误构建。实际项目中还应该把 package.json、锁文件和环境变量声明进去，确保依赖变更后缓存能够正确刷新。
文件系统缓存不是简单地把上一次的 output 直接保存下来，而是缓存模块转换结果、依赖图信息和 chunk 生成过程中的中间数据。因此即使修改了单个文件，缓存命中率依然很高。根据项目规模和机器条件，二次构建时间通常能缩短 50% 到 90%。这里需要注意，缓存目录不应放在会被 CI 清理的临时目录中，最好通过 cacheDirectory 显式指定到项目内的可复用路径。在多人协作或容器化环境中，还要考虑缓存目录的权限和共享策略。
更精细的 Tree Shaking 与资源模块
Tree Shaking 并不是 Webpack 5 才有的概念，但 Webpack 5 在模块分析和未使用代码消除上做了更细粒度的优化。Webpack 4 对未使用的导出项有时无法彻底剔除，尤其是嵌套的命名导出和某些副作用场景。Webpack 5 通过改进模块连接算法，能够更准确地识别出一个模块中哪些导出被真正使用，并在生产构建中剔除孤立代码。
要让 Tree Shaking 发挥最大效果，除了设置 mode: 'production'，还应该在 package.json 中声明 sideEffects 字段。例如一个组件库如果只有样式文件存在副作用，可以这样声明。
{
"name": "my-ui-library",
"version": "1.0.0",
"sideEffects": [
"*.css",
"*.scss"
]
}
这样做是在告诉 Webpack：除了 CSS 和 SCSS 文件，其余模块都可以安全地执行未使用代码删除。Webpack 5 对 sideEffects 的判断也比上一代更加可靠，配合 ESM 的 import/export 语法，能够有效减少 bundle 体积。实际项目中还需要注意避免使用 CommonJS 的 require 和动态属性访问，这类写法会破坏静态分析，导致 Tree Shaking 失效。
此外，Webpack 5 将原先常用的 file-loader、url-loader 和 raw-loader 统一成 Asset Modules。通过 type: 'asset/resource'、type: 'asset/inline' 和 type: 'asset/source'，开发者不再需要安装额外 loader。配合 parser.dataUrlCondition.maxSize，可以让小于阈值的图片自动转换为 base64 内联，大于阈值则输出为独立文件。这种内置化降低了配置复杂度，也让资源处理行为更可预测。
升级迁移与常见坑点
从 Webpack 4 升级到 5 并不是纯收益，也有需要主动处理的破坏性变更。最常遇到的是 Webpack 5 不再自动为 Node.js 核心模块提供 polyfill。如果项目代码或依赖中使用了 Buffer、process、crypto 等 Node 全局对象，升级后会直接报错。此时需要按需安装 buffer、process 等 npm 包，并在配置中通过 resolve.fallback 手动声明。
// webpack.config.js
const webpack = require('webpack');
module.exports = {
resolve: {
fallback: {
buffer: require.resolve('buffer/'),
process: require.resolve('process/browser'),
},
},
plugins: [
new webpack.ProvidePlugin({
Buffer: ['buffer', 'Buffer'],
process: 'process/browser',
}),
],
};
这段配置只应在确实需要兼容浏览器端 Node polyfill 时使用。更推荐的做法是排查依赖，去掉无关的 Node 核心模块引用，减少最终产物体积。另一个迁移问题是 chunk ID 生成策略的变化。Webpack 5 默认使用 deterministic 的 chunk id，这有利于长效缓存，但如果项目中依赖了固定的数字 ID 或文件名，需要注意生成的 chunk 文件名可能发生变化。
还有一点容易被忽略：Webpack 5 对 contenthash 和 output.chunkFilename 的处理更严格，某些旧版插件可能不再兼容。升级前建议先梳理 plugins 列表，确认社区插件是否已提供 Webpack 5 兼容版本。通过小步验证、逐步开启持久化缓存和模块联邦，可以在享受 Ambition 特性红利的同时降低迁移风险。