Webpack 5 的发布可以说是前端工程化领域一次重量级的更新，官方在版本说明里用了相当大的篇幅来描述这次改动的规模，社区也常拿解放宇宙这样的说法来形容它的变化幅度。相比 Webpack 4 的渐进式优化，Webpack 5 在底层架构上做了大量重构：长期缓存的可靠性被重新设计，Node.js polyfill 的默认注入被移除，资源处理从 file-loader、url-loader 过渡到原生 Asset Modules，同时还带来了微前端开发者期待已久的 Module Federation。这篇文章就从几个核心特性入手，聊聊它们解决了什么问题，以及实际项目中该怎么用。
持久化缓存：File System Cache 带来的构建提速
Webpack 4 时代的缓存机制比较割裂：babel-loader 有自己的 cacheDirectory，terser 插件有 cache 选项，各个 loader 和插件各自为政，缓存命中条件苛刻，稍微改一下配置文件整个缓存就作废了。Webpack 5 把缓存统一收归到编译器层面，通过 cache.type: 'filesystem' 开启基于文件系统的持久化缓存，第一次构建时会把模块解析结果、依赖图、代码生成产物全部序列化到 node_modules/.cache/webpack 目录，第二次构建直接跳过大量重复工作。
实际配置非常简单，只需要在 webpack.config.js 中加入几行：
module.exports = {
cache: {
type: 'filesystem',
// 构建依赖变化时自动让缓存失效，比如配置文件、环境变量文件
buildDependencies: {
config: [__filename]
},
// 缓存版本号，配置变化时手动递增
version: 'v1'
}
};这里有个细节值得注意：buildDependencies 的作用是声明哪些文件会影响构建结果。把配置文件本身加进去之后，一旦你修改了 webpack.config.js，Webpack 会自动检测到变化并让缓存失效，避免出现改了配置但产物还是旧的这种诡异问题。如果你依赖 .env 之类的环境文件，也应该把它们加进来。
从实测数据来看，中大型项目开启文件系统缓存后，二次冷启动构建（重新打开终端后的构建）通常能提升 60% 到 90% 的速度，因为不再需要重新解析 node_modules 里成千上万个模块。配合 cacheCompression 选项还可以对缓存文件做 gzip 压缩，减少磁盘占用。不过要注意，CI 环境中如果想利用缓存，需要把缓存目录持久化下来，否则每次都是全新构建，缓存就失去意义了。
模块联邦：微前端架构的官方解法
Module Federation（模块联邦）是 Webpack 5 最亮眼的新功能，它允许多个独立构建、独立部署的应用之间在运行时共享模块。打个比方，你有两个独立的 SPA 应用，A 应用想使用 B 应用里的某个组件，传统做法要么发布成 npm 包手动同步版本，要么用 iframe 隔离牺牲体验。模块联邦提供了第三条路：B 应用把组件以远程模块的形式暴露出去，A 应用在运行时动态加载，而且双方可以共享同一份依赖，比如 React 只会被加载一次。
下面是一个最小化的示例，宿主应用如何消费远程模块：
// 宿主应用的 webpack 配置
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
remotes: {
// 远程应用别名：外部容器名@远程地址/容器文件名
shopApp: 'shopApp@http://localhost:3001/remoteEntry.js'
},
shared: {
react: { singleton: true },
'react-dom': { singleton: true }
}
})
]
};
// 业务代码中直接引入远程模块
import ProductList from 'shopApp/ProductList';远程应用那边则需要用 exposes 字段把内部模块暴露出去，同时同样声明 shared。singleton: true 是一个关键配置，它保证 React 这类有全局单例要求的库在页面中只会存在一份实例，避免出现多个 React 副本导致的 hooks 报错。shared 还支持指定版本范围，比如 requiredVersion: '^18.0.0'，版本不匹配时框架会给出警告。
模块联邦的典型应用场景包括微前端架构中的公共组件复用、大型系统的按团队拆分部署、以及灰度发布时的动态能力下发。但它也不是没有代价：远程模块加载失败的处理、类型提示的同步、本地开发的代理配置都需要额外投入。如果是新项目可以直接尝试，老项目改造建议先从非关键页面切入验证。
Asset Modules 与移除 Node.js Polyfill
Webpack 5 把资源处理内置化了。以前要装 file-loader、url-loader、raw-loader 才能处理图片和字体，现在只需要配置 type 字段，常见取值有 asset/resource（发射单独文件，相当于 file-loader）、asset/inline（转 base64 内联，相当于 url-loader）、asset（按大小自动选择，相当于 url-loader 带 limit）、asset/source（导出源码字符串，相当于 raw-loader）。
module.exports = {
module: {
rules: [
{
test: /\.(png|jpe?g|gif|svg)$/,
type: 'asset',
parser: {
dataUrlCondition: {
// 小于 8kb 内联为 base64，超过则生成单独文件
maxSize: 8 * 1024
}
}
},
{
test: /\.(woff2?|ttf|eot)$/,
type: 'asset/resource',
generator: {
filename: 'fonts/[name].[hash][ext]'
}
}
]
}
};另一个影响面更大的变更是默认不再自动注入 Node.js 核心模块的 polyfill。Webpack 4 时代，如果你在浏览器代码里不小心 require 了 crypto 或者 path，Webpack 会自动打包对应的 polyfill，结果产物里多出一大坨浏览器根本用不到的代码。Webpack 5 直接砍掉了这个行为，遇到此类引用会直接报错提示你自行决定。解决方案有三种：在前端代码里改用对应功能的浏览器原生 API 或社区轻量库；通过 resolve.fallback 手动指定替代品；或者干脆用 externals 排除掉。
除了上面这些，Webpack 5 在 Tree Shaking 方面也增强了嵌套导出的分析能力，支持了顶层的 await，产物默认支持 ES6 语法输出（output.ecmaVersion），开发模式下还内置了更友好的错误提示。从 Webpack 4 迁移时，重点检查 loader 版本兼容性、被移除的配置项（比如 mode 必填）以及资源处理规则的改写，官方还提供了 node_modules-check 之外更实用的迁移指南，建议先在分支上跑通再合入主干。总体来说，这次大版本更新虽然破坏性不小，但换来的构建速度、产物体积和架构能力提升，绝对值得投入时间升级。