Webpack 5 发布之后，社区里流传着一个有趣的说法，叫 Clear Universe 清除宇宙。这个词并不是官方文档里的正式术语，而是开发者对 Webpack 5 这套大规模清理动作的形象概括：它清掉了历史包袱，清掉了无用的 polyfill，清掉了堆积的缓存垃圾，让整个构建体系轻装上阵。理解这套清理逻辑，是顺利从 Webpack 4 迁移到 Webpack 5 的第一步。
一、Clear Universe 到底清掉了什么
Webpack 4 时代积累的问题相当多。为了兼容老项目，它保留了大量的废弃 API，比如 module.loaders、loaderContext.options 这些早期写法，在 Webpack 5 里被彻底删除。与此同时，Webpack 4 会默认为浏览器环境注入 Node.js 的 polyfill，例如 assert、buffer、process 等模块，即使你的前端代码根本用不到它们。这导致打包体积莫名其妙地膨胀，很多开发者抱怨自己的 bundle 里凭空多出几十 KB 的 Node 代码。
Webpack 5 的清理策略可以归纳为三个层面：第一层是源码层面的清理，官方重写了内部模块系统，删除了超过两千个废弃的语法和接口；第二层是运行时层面的清理，不再自动注入 polyfill，遇到引用 Node 内置模块的代码会直接报错提示你手动处理；第三层是缓存层面的清理，配合全新的持久化缓存机制，自动识别并删除失效的缓存快照。
这套清理带来的直接收益是构建产物更干净、二次构建更快。以一个中等规模的 React 项目为例，迁移到 Webpack 5 之后，仅移除自动 polyfill 这一项就能减少约 20KB 到 60KB 的产物体积，具体数值取决于依赖库里对 Node API 的引用程度。
二、移除自动 polyfill：最需要注意的破坏性变更
清理 polyfill 是 Webpack 5 最容易引发构建报错的地方。当你的代码或者第三方依赖引用了 process.env.NODE_ENV、Buffer 这类 Node 全局对象时，Webpack 4 会默默帮你补上实现，而 Webpack 5 会直接抛出类似于 Module not found: Error: Can't resolve 'buffer' 的错误。
解决方式有两种。如果确实需要这些能力，就手动安装对应的 polyfill 包并在 resolve.fallback 中声明：
module.exports = {
resolve: {
fallback: {
buffer: require.resolve('buffer/'),
process: require.resolve('process/browser'),
path: false, // 明确不需要的模块置为 false，避免误打包
},
},
plugins: [
new webpack.ProvidePlugin({
Buffer: ['buffer', 'Buffer'],
process: 'process/browser',
}),
],
};另一种思路更符合清理精神：如果依赖只是 incidental 地引用了 Node 模块，可以先用 resolve.fallback 把它置为 false，然后观察运行时是否真的调用了相关 API。很多库在浏览器环境下根本不会走到那些分支，直接屏蔽反而是最优解。
值得注意的是，这种清理让报错提前到了构建阶段，而不是把问题隐藏到线上。短期看迁移成本增加了，长期看它逼着开发者正视依赖的真实行为，这正是 Clear Universe 想传达的设计哲学：不留垃圾，不留隐患。
三、持久化缓存与自动垃圾清除
如果说移除 polyfill 是清理过去，那持久化缓存就是管理现在。Webpack 5 引入了基于文件系统的缓存，配置非常简单：
module.exports = {
cache: {
type: 'filesystem',
buildDependencies: {
// 配置文件变更时让缓存失效
config: [__filename],
},
cacheDirectory: 'node_modules/.cache/webpack',
},
};开启之后，第一次冷构建会稍慢，因为要把模块编译结果写入磁盘；从第二次构建开始，没有变化的模块直接从缓存读取，构建速度普遍能提升 60% 到 90%。对于 CI 环境，可以把缓存目录挂载为可持久化的 artifact，跨流水线复用。
这套缓存机制同样内置了清除策略。Webpack 会为每个缓存条目记录版本号和依赖快照，当 webpack 版本、配置内容或者依赖文件发生变化时，旧的缓存条目会被标记为过期并在下次构建时自动清理，不需要你手动去删 node_modules/.cache 目录。此外，通过 cache.version 字段可以手动划分缓存命名空间，比如针对不同分支设置不同的版本字符串，避免缓存串用。
需要提醒的是，如果你的构建流程会动态生成代码或者使用了输出内容不确定的 loader，务必通过 snapshot.managedPaths 或者 loader 的 cacheable 标记把不可缓存的环节排除出去，否则可能出现构建结果不更新的诡异问题。这也是清理机制的反面：缓存清除依赖准确的依赖追踪，追踪不准就会留下脏数据。
四、升级迁移的实操建议
结合 Clear Universe 的清理范围，迁移时建议按三步走。第一步，先解决破坏性变更：全局搜索项目里对 webpack.NamedModulesPlugin、webpack.HashedModuleIdsPlugin 的引用，前者已被移除，改用 optimization.moduleIds 配置；检查 node 配置项里的 node: { fs: 'empty' } 旧写法，这些在 Webpack 5 中都不再支持。
第二步，处理 polyfill 报错。推荐使用官方提供的迁移辅助：运行 npx webpack serve 时开启 --stats-error-details，错误信息会明确指出是哪个依赖在引用哪个 Node 模块，逐个用 fallback 解决即可。同时检查 babel 和 core-js 的版本，Webpack 5 要求 core-js 大于等于 3.0.1，旧版本会直接报错。
第三步，享受清理后的红利。开启持久化缓存、按需开启 experiments.css 和模块联邦，逐步把构建体系调整到 Webpack 5 的推荐形态。整个迁移过程中，保持每次只改一个变量、跑一次完整构建的习惯，能让定位问题变得简单得多。清理宇宙的意义不在于删掉多少代码，而在于让构建系统重新回到一个干净、可预测的起点。
Webpack 5Clear Universe持久化缓存修改时间：2026-09-14 01:24:46