什么是 Lifter Universe 提升者宇宙
Webpack 5 的官方文档和源码中并没有直接出现 Lifter Universe 这个词，它是国内社区对 Webpack 5 一整套模块提升机制的统称。这套体系包括了作用域提升、模块串联、Tree Shaking 强化以及基于 Module Graph 的深度优化。之所以用宇宙来形容，是因为这些提升能力并不是孤立工作的，而是像星系一样相互关联、层层递进，共同决定最终打包产物的体积和执行效率。
要理解这套机制，首先要回顾打包器的一个核心矛盾：为了支持 CommonJS、AMD、ES Module 等多种模块规范，Webpack 需要在产物中注入运行时代码，把每个模块包装成一个个函数，再通过 __webpack_require__ 来模拟模块加载。这种包装带来了额外的函数调用开销和体积开销。而提升机制的目标，就是在保证语义正确的前提下，尽可能把多个模块的代码合并、内联，甚至直接消除包装层，让产物接近手写代码的执行效率。
在 Webpack 4 中，生产模式下就已经默认开启了 optimization.concatenateModules，也就是作用域提升的雏形，但它的能力相当有限，只要模块之间存在任何动态特性，比如被 require.ensure 引用、存在循环依赖或者模块被多个 chunk 共享，提升就会被放弃。Webpack 5 对整个提升管线做了重写，引入了更精细的模块分析和判定的代码，这也是社区敢用宇宙来形容它的原因。
作用域提升的工作原理与限制条件
作用域提升的核心思想源自 Rollup：当多个 ES Module 之间存在静态的 import 和 export 关系时，可以把它们的代码拼接进同一个作用域，省去模块包装函数和运行时调用。举例来说，如果入口文件导入了两个工具模块，Webpack 5 在分析模块图之后，会发现这三个模块之间只存在静态依赖，于是把它们合并成一个作用域，产物中不再有独立的模块定义。
// math.js
export function add(a, b) {
return a + b;
}
export function mul(a, b) {
return a * b;
}
// index.js
import { add, mul } from './math.js';
console.log(add(1, 2));
console.log(mul(3, 4));上面这段代码在 Webpack 5 的生产模式下，两个文件会被合并处理，add 和 mul 直接以普通函数的形式出现在同一个模块作用域中。更重要的是，配合 Tree Shaking，如果 mul 从未被使用，它会在压缩阶段被整体移除。在 Webpack 4 中，由于模块包装的存在，未使用的导出即使被标记也需要压缩器做更激进的分析才能删掉，删除成功率明显低于 Webpack 5。
不过作用域提升并非万能，以下几种情况会导致提升失败，需要特别注意：
- 模块使用了非严格模式的代码，也就是没有 ESM 语义的 CommonJS 模块无法参与提升。
- 存在循环依赖的模块会被排除在提升范围之外，避免执行顺序被改变。
- 被多个异步 chunk 共享的模块，为了保持按需加载语义，通常不会被合并进父级作用域。
- 动态导入
import()的目标模块本身就是独立 chunk 的边界，不会跨边界提升。
理解这些限制非常重要，因为很多团队升级到 Webpack 5 后发现体积没有明显下降，问题往往出在依赖中混用了大量 CommonJS 包，或者模块图里循环依赖过多。可以通过 webpack-bundle-analyzer 观察产物结构，再结合 stats 信息中的 concatenatedModules 字段确认提升是否生效。
Webpack 5 在提升体系上的具体改进
相比 Webpack 4，Webpack 5 的提升体系有几个值得关注的改进点。第一是嵌套导出的处理能力增强，当 A 模块从 B 模块 re-export，B 又从 C 模块 re-export 时，Webpack 5 能把这条导出链一路追溯到底层定义，直接把最内层的绑定交给使用者，中间的转发层在产物中会被完全消除。这种链式追踪在 Webpack 4 中经常在第二层就断了。
第二是 sideEffects 字段的利用更加充分。包作者的 package.json 中声明 sideEffects: false 后，Webpack 5 可以更放心地把未引用的模块整体丢弃。对于有副作用的文件，还可以通过数组精确列出，例如 sideEffects: ["*.css", "./src/polyfill.js"]，让样式文件和垫片代码不被误删。如果你的项目是自己维护的组件库，正确书写这个字段对下游使用者的产物体积影响非常大。
// webpack.config.js
module.exports = {
mode: 'production',
optimization: {
// Webpack 5 生产模式默认开启
concatenateModules: true,
usedExports: true,
// 内部模块图中进一步标记可安全移除的模块
providedExports: true,
},
// 告知 Webpack 代码无副作用，放开 Tree Shaking
module: {
rules: [
{
test: /\.m?js$/,
resolve: {
fullySpecified: false,
},
},
],
},
};第三是持久化缓存与提升机制的配合。Webpack 5 引入的 filesystem cache 会把模块图的分析结果、导出关系、副作用标记一起缓存下来。这意味着第二次构建时，提升判定可以直接复用缓存结论，不需要重新遍历分析，冷构建与热构建的差距被显著拉开。在大中型项目中，二次构建时间常常能缩短到原来的三分之一以下。
还有一个容易被忽略的点是 optimization.innerGraph，也就是内部模块图分析。它允许 Webpack 追踪变量在模块内部的传递路径，例如一个导出函数被赋值给局部变量后再被使用，Webpack 5 依然能判断出这个绑定是否真的被消费。这种细粒度分析让压缩器拿到更精确的存活信息，最终产物中的死代码残留更少。
实践建议与常见踩坑排查
想在项目中最大化利用这套提升体系，建议从依赖治理入手。优先选择提供 ESM 版本产物的依赖包，查看包的 package.json 中 module 或 exports 字段是否指向 ES Module 文件。对于只提供 CommonJS 的老包，考虑寻找现代化替代品，或者通过按需引入的方式减小影响面。工具类库方面，lodash 应使用 lodash-es，日期处理可考虑 dayjs 这类体积可控且 ESM 友好的方案。
其次要警惕 Babel 配置对提升的破坏。如果 @babel/preset-env 把 ES Module 编译成了 CommonJS，那么 Webpack 看到的就全是动态模块语义，提升和 Tree Shaking 都会失效。正确做法是在 Babel 配置中设置 modules: false，把模块转换的工作完全留给 Webpack 处理。这是实际项目中最常见的一类问题，排查时可以先确认产物中是否还存在 __webpack_require__ 大量包装的痕迹。
// babel.config.js
module.exports = {
presets: [
[
'@babel/preset-env',
{
// 关键配置：保留 ESM 语法交给 Webpack 处理
modules: false,
targets: '> 0.25%, not dead',
},
],
],
};验证提升效果时，可以用固定的一组业务代码分别跑 Webpack 4 和 Webpack 5 构建，对比产物体积和模块数量。一种直观的检查方式是搜索产物源码中是否还存在 Object.defineProperty(exports, ...) 这类 CommonJS 兼容代码，越少说明提升越彻底。另外开启 profile: true 后查看 stats，可以清楚看到哪些模块被 concatenate，哪些因为依赖问题被排除。
最后提醒一点，提升机制优化的主要是同步加载路径上的代码，对于路由级代码分割带来的性能收益，仍然要依赖合理的 splitChunks 策略和 import() 的使用位置。把提升、分割、缓存这三张牌一起打好，Webpack 5 的性能潜力才能真正释放出来。如果你的项目还停留在 Webpack 4，仅仅是升级构建工具版本，配合依赖治理，通常就能拿到两位数百分比级别的体积下降，这笔收益非常值得投入。