Webpack 5 作为前端构建工具的重要版本，在性能、配置复杂度以及多应用协作方面都做出了实质性改动。过去不少团队在升级后没有正确开启新机制，导致构建反而变慢，其实是因为没有理解其内部缓存与模块处理思路的变化。本文从持久化缓存、模块联邦以及资源模块三个角度，详细说明这些新特性如何落地。
持久化缓存如何改写二次构建体验
在 Webpack 4 及更早版本中，缓存主要依赖内存存储，每次关闭命令行工具后缓存即丢失，再次启动必须全量编译。Webpack 5 引入了基于文件系统的持久化缓存，默认会将编译中间结果写入 node_modules/.cache/webpack 目录。这意味着只要源码与依赖未发生变化，二次启动可以直接复用已有缓存，大幅度缩短等待时间。
开启方式十分简单，只需要在配置中设置 cache.type 为 filesystem。你还可以指定缓存路径与版本，避免不同项目间产生污染。以下示例展示了基础配置：
const path = require('path');
module.exports = {
mode: 'development',
cache: {
type: 'filesystem',
cacheDirectory: path.resolve(__dirname, 'node_modules/.cache/webpack'),
buildDependencies: {
config: [__filename]
}
},
entry: './src/index.js',
output: {
filename: 'bundle.js',
path: path.resolve(__dirname, 'dist')
}
};
需要注意的是，当构建配置文件本身发生变动时，应通过 buildDependencies 声明，这样 Webpack 会智能失效旧缓存。相比自行接入第三方缓存插件，原生方案在兼容性与维护成本上优势明显，也降低了因缓存错乱引发的奇怪报错。
模块联邦解决了什么协作难题
微前端架构下，多个独立部署的应用常常需要复用同一套组件或工具函数。传统做法是将公共代码打包成 npm 包，任何改动都要经历发布、安装、重新构建的漫长链路。Webpack 5 的模块联邦允许运行时动态加载远程模块，各应用可互相暴露或消费代码，而不必提前打包进自身产物。
核心配置围绕 ModuleFederationPlugin 展开。一个应用可作为宿主，另一个作为远程，双方通过 remotes 与 exposes 建立映射。下面给出远程端暴露组件的写法：
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'remoteApp',
filename: 'remoteEntry.js',
exposes: {
'./Button': './src/components/Button.js'
},
shared: ['react', 'react-dom']
})
]
};
宿主端则通过 remotes 指向远程入口，在代码中以普通 import 方式使用。共享依赖 shared 字段能避免重复加载 React 等库，显著减少总体积。这种机制特别适合中大型团队拆分业务边界，但也要注意版本协商失败会导致运行时报错，因此建议锁定主版本一致。
资源模块怎样替代旧版加载器
过去处理图片、字体等静态资源，需要组合 file-loader、url-loader 与 raw-loader，并根据大小写判断内联或分离。Webpack 5 原生提供了资源模块类型，包括 asset/resource、asset/inline、asset/source 和 asset，用统一规则替代繁琐配置。
以图片为例，只需在 module.rules 中声明类型，即可自动按阈值处理。示例代码如下：
module.exports = {
module: {
rules: [
{
test: /.(png|jpe?g|gif)$/i,
type: 'asset',
parser: {
dataUrlCondition: {
maxSize: 8 * 1024
}
}
}
]
}
};
当文件小于 8KB 时自动转 base64 内联，否则输出独立文件。这样既减少了依赖安装量，也令构建逻辑更直观。配合持久化缓存，资源哈希生成更稳定，浏览器长缓存命中率提高。整体来看，Webpack 5 的这些改动不是表面语法糖，而是从工程效率底层做了重新梳理，值得在升级时认真规划迁移路径。