Sweep Universe 清扫宇宙这个说法最早来自社区对 Webpack 5 构建优化效果的调侃：升级之后，产物体积变小、构建速度变快，仿佛有人把整个项目宇宙里的垃圾模块都清扫了一遍。事实上，Webpack 5 并没有一个叫 Sweep Universe 的官方配置项，它代表的是一整套模块级清理能力的集合，包括增强的 Tree Shaking、持久化缓存、移除自动 Node.js Polyfill、更好的模块合并策略等。理解这套机制的工作原理，对优化中大型项目的构建效率非常关键。
一、清扫宇宙的核心：增强版 Tree Shaking 与死代码消除
Tree Shaking 并不是 Webpack 5 首创的，但 Webpack 5 对它做了大幅增强。Webpack 4 只能对简单的 export 做静态分析，而 Webpack 5 引入了更精细的模块图分析能力，可以对嵌套的导出、重新导出的变量，甚至部分 CommonJS 代码进行追踪和标记。编译器会在构建过程中给每个模块打上标记，最终由压缩阶段统一剔除从未被使用的导出内容。
要让这套机制充分发挥作用，package.json 中的 sideEffects 字段至关重要。它告诉编译器哪些文件是有副作用的，哪些可以放心清理：
{
"name": "my-app",
"sideEffects": false
}
上面的配置表示整个包都没有副作用，可以放心做激进的清理。但如果项目里存在引入即生效的文件，比如全局样式、polyfill 脚本，就必须明确声明，否则会被误删：
{
"sideEffects": [
"*.css",
"*.scss",
"./src/polyfills.js"
]
}
这里有一个非常经典的坑：不少团队把 sideEffects 直接设为 false，结果线上页面样式全部丢失。原因是 CSS 文件本身不导出任何被引用的变量，属于典型的副作用文件。排查这类问题时可以在构建命令中加上 --analyze 或使用 stats 配置查看模块被剔除的详情。
二、持久化缓存：让二次构建快到起飞
如果说 Tree Shaking 负责清扫产物里的垃圾，那么持久化缓存（Persistent Caching）清扫的就是构建时间。Webpack 4 的缓存只存在于内存中，每次重启 dev server 都要全量重新编译。Webpack 5 把缓存搬到了文件系统，基于文件内容的时间戳和 hash 判断哪些模块无需重新构建，二次启动速度通常能提升 60% 到 90%。
开启方式非常简单，在生产构建中配置 cache: build => ... 的形式可以为不同分支维护独立缓存：
// webpack.config.js
module.exports = {
cache: {
type: 'filesystem',
buildDependencies: {
// 配置文件本身变化时，缓存自动失效
config: [__filename]
},
cacheDirectory: path.resolve(__dirname, '.webpack_cache'),
version: '1.0.0'
}
};
有几个细节需要注意。第一，buildDependencies 一定要把 webpack 配置文件、babel 配置文件纳入，否则改了配置但缓存没有失效，会出现诡异的构建结果。第二，version 字段可以用作手动开关，升级依赖后如果怀疑缓存脏了，改一下版本号即可强制全量重建。第三，缓存目录建议加入 .gitignore，避免提交到仓库。
另外，Webpack 5 对 loader 的缓存粒度也更细了。像 babel-loader、css-loader 这类耗时大户，配合持久化缓存后基本能做到只在源码变化时局部重编，这也是清扫宇宙体感最明显的一部分。
三、移除自动 Polyfill 与模块联邦：瘦身与按需的新思路
Webpack 5 还做了一次颇具争议但方向正确的清理：移除了对 Node.js 核心模块的自动 Polyfill。在 Webpack 4 时代，只要你的前端代码或者某个依赖里出现了 process、Buffer、crypto 这类引用，Webpack 会自动注入对应的 polyfill，导致产物悄悄膨胀。Webpack 5 选择了报错提示，强迫开发者显式声明到底要不要这些能力：
module.exports = {
resolve: {
fallback: {
path: false, // 不需要，直接置为 false
crypto: require.resolve('crypto-browserify')
}
}
};
这种做法短期内会增加迁移成本，尤其是一些老的三方库会直接编译报错，但长期看它把体积控制权还给了开发者。排查这类报错时，错误信息会明确指出是哪个模块引用了哪个 Node 核心模块，按提示逐个处理即可。
与清扫相对的是按需引入，Module Federation 模块联邦提供了另一个维度的能力：多个独立构建的应用之间共享模块，运行时按需加载。它和清扫机制配合使用，可以让宿主应用只保留必须的代码，公共依赖通过 shared 配置去重：
new ModuleFederationPlugin({
name: 'host',
remotes: {
remoteApp: 'remoteApp@http://cdn.ipipp.com/remote/remoteEntry.js'
},
shared: {
react: { singleton: true },
'react-dom': { singleton: true }
}
})
这里的 singleton: true 保证整个页面只会加载一份 React 实例，既减少了重复代码，也避免了多实例带来的状态同步问题。
四、落地建议与常见问题排查
对于准备接入这套清理机制的项目，建议按三步走。第一步先解决 Node Polyfill 报错，保证项目能正常构建；第二步开启持久化缓存，观察 CI 环境的构建耗时变化，注意 CI 上需要配置缓存上传下载才能受益；第三步再精细化调整 Tree Shaking 相关配置，检查各依赖包是否都正确声明了 sideEffects。
验证清理效果最直观的工具是官方推荐的 webpack-bundle-analyzer。对比升级前后的产物可视化图，重点观察 node_modules 区域是否有大块的冗余模块残留。如果发现某些库没有被有效摇掉，通常是该库发布的是 CommonJS 格式或未设置 sideEffects，此时可以考虑用别名指向其 ESM 版本，或者向上游提 issue。
总结来看，Sweep Universe 清扫宇宙本质上是 Webpack 5 从编译器底层对无用代码和无谓计算的全面清理。理解每个环节的原理，配置时避开 sideEffects 误删、缓存失效不及时这些坑，就能让项目在体积和速度上同时受益。构建优化从来不是一次性工作，建议在团队内建立产物体积监控，把清扫效果长期固化下来。
Webpack 5Sweep UniverseTree Shaking修改时间：2026-09-04 02:46:44