Webpack 5 是这个构建工具自诞生以来变化最大的一个大版本。它不再只是修修补补的性能优化，而是从缓存机制、模块系统到长期缓存算法都做了底层重构。很多项目升级后发现构建时间从几分钟降到几十秒，也有项目因为 Node.js polyfill 被移除而直接报错。这篇文章会系统地讲清楚 Webpack 5 到底改了什么，以及这些改动对你的项目意味着什么。
持久化缓存：构建速度质变的第一功臣
Webpack 4 时代的缓存主要靠 cache-loader 和各种社区插件勉强支撑，缓存策略零散且效果有限。Webpack 5 把缓存直接内置到了核心，通过配置 cache.type 就能启用基于文件系统的持久化缓存。第一次构建时 webpack 会把每个模块的处理结果写入磁盘，之后的构建只要依赖没有变化，就可以直接跳过 loader 的编译和 ast 解析过程，仅做模块关系的重新组装。
启用方式非常简单，只需要在配置文件中加几行：
module.exports = {
cache: {
type: 'filesystem',
buildDependencies: {
// 推荐把 webpack 配置文件本身纳入依赖，配置变更后缓存自动失效
config: [__filename]
},
cacheDirectory: path.resolve(__dirname, '.webpack_cache')
}
};这里有一个容易被忽视的细节：buildDependencies 的作用是声明哪些文件会影响构建结果。如果没有把 babel 配置、postcss 配置这些文件加进去，一旦修改它们，旧缓存仍然会被复用，导致代码没有按预期更新，这类问题排查起来非常折磨人。另外缓存目录默认放在 node_modules/.cache/webpack 下，在 CI 环境中建议配置缓存恢复策略，否则每次流水线都是冷启动，持久化缓存的优势完全发挥不出来。
长期缓存算法改进与 Tree Shaking 增强
Webpack 4 的 [contenthash] 其实是间接计算出来的，模块id和引用关系的变化都会干扰最终的哈希值，经常出现只改一行代码却导致大量 chunk 哈希变化的情况，浏览器缓存基本失效。Webpack 5 引入了真正的 [contenthash] 算法，直接对文件内容做哈希，同时默认采用确定性算法生成 module id 和 chunk id，替代了原来的数字自增 id。这意味着只要模块内容不变，产物的文件名就稳定不变，配合 CDN 缓存策略可以显著提升用户二次访问的加载速度。
Tree Shaking 方面，Webpack 5 支持了嵌套的无用代码消除。比如你在代码里写了 import { map } from 'lodash-es'，即使这个 import 被包在多层函数或者条件分支里，webpack 也能分析出哪些导出没有被真正使用并移除。此外新增的 sideEffects 配合 package.json 中的声明，可以更精确地标记模块是否包含副作用，进一步压缩产物体积。实际项目中，从 Webpack 4 迁移过来后产物体积下降百分之十到二十是比较常见的。
模块联邦：微前端落地的新选项
模块联邦（Module Federation）是 Webpack 5 中最亮眼的新能力，它允许多个独立构建的应用在运行时共享模块。传统微前端方案通常依赖 npm 包发布或者运行时动态加载脚本，前者更新链路长，后者缺乏类型支持和依赖管理。模块联邦把这两个问题都解决了：宿主应用可以像正常 import 一样消费远程应用暴露的组件，而公共依赖如 React 可以声明为共享依赖，由 webpack 在运行时协商版本，只加载一份。
// 远程应用的 webpack 配置
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'remoteApp',
filename: 'remoteEntry.js',
exposes: {
'./Button': './src/components/Button'
},
shared: { react: { singleton: true }, 'react-dom': { singleton: true } }
})
]
};
// 宿主应用中直接消费远程组件
const RemoteButton = React.lazy(() => import('remoteApp/Button'));
function App() {
return (
<Suspense fallback={"loading"}>
<RemoteButton />
</Suspense>
);
}需要提醒的是，模块联邦并不是银弹。它要求所有参与方都使用 Webpack 5 以上版本，跨团队协作时远程服务的可用性会直接影响宿主页面，shared 依赖的版本协商在版本差距较大时也可能出现加载两份依赖的情况。对于团队规模不大、模块拆分需求不强烈的场景，贸然引入模块联邦反而会增加架构复杂度。
升级迁移的常见坑与应对
Webpack 5 移除了对 Node.js 核心模块的自动 polyfill，这是升级过程中最高频的报错来源。比如代码里直接引用了 process、buffer 或者某个依赖包内部 require 了 crypto，构建时就会抛出类似 breaking change 的错误提示。正确的做法分两步：先判断这段代码是否真的需要跑在浏览器里，如果不需要，在 resolve.fallback 中显式设为 false 排除掉；如果确实需要，再通过 resolve.alias 或 fallback 指向对应的 npm 包。
其他注意事项还包括：Node.js 运行环境至少需要 10.13 以上；webpack-dev-server 命令被移除，需要单独安装 v4 版本的 dev-server；一些老旧插件的兼容版本必须同步升级，比如 html-webpack-plugin 至少要 5.x。建议升级前先用 webpack bundle analyzer 记录当前的产物结构，升级后做一次对比，确认没有模块意外丢失或重复打包。整体来看，只要把 polyfill 问题处理好，大多数项目升级 Webpack 5 的工作量是可控的，而换来的构建速度和缓存收益绝对值得投入。