当 webpack 把几百个模块打包进同一个 bundle 时，默认会为每个模块生成一段包裹函数 。这些函数在运行期通过 __webpack_require__ 逐个调用，保证了模块作用域互不干扰，却也带来了额外的函数调用开销与体积膨胀。Scope Hoisting（作用域提升）正是为了拆除这道"隔离墙"，让模块内容直接合并进更大的作用域，从而减少函数数量、提升执行效率。
一、隔离墙的诞生
在 webpack 3 之前，所有模块被转译成如下形式：
js
function(module, exports, __webpack_require__) {
// 模块 A 的源码
}运行期通过索引调用这些闭包，相当于在浏览器里模拟 CommonJS 的同步 require。虽然安全，但每多一个模块就多一次闭包创建与调用，CPU 与内存都不讨好。
二、作用域提升的机理
Scope Hoisting 的核心思想是静态分析 + 代码合并。webpack 会在生产模式下启用 ModuleConcatenationPlugin，流程大致如下：
- 构建依赖图：遍历模块，标记所有导入导出。
- 闭包消除：将模块代码平铺到同一个函数作用域，同时重命名冲突标识符。
- 作用域链重构 ：通过 AST 重写，确保
import/export语义不变，但不再产生运行时闭包。
最终产物里，原本分散的几十个小函数被"拍扁"成一段连续代码，模块间引用变成普通变量访问，直接去掉一层函数调用栈。
三、启用条件与边界情况
为了安全合并作用域，webpack 要求模块满足：
- 必须是 ESM 格式（
import/export静态声明）； - 不能出现循环依赖多次引用；
- 不能包含动态导入
import()； - 不能是 CommonJS 或 AMD 模块。
只要任一条件不成立，当前模块及其子树会回退到传统包裹函数，保证行为一致。
四、收益量化
以典型的中型应用为例，开启 Scope Hoisting 后常见指标：
- 包体积减少 5%～15%，主要节省函数声明与闭包开销；
- 运行时 CPU 占用降低，尤其在启动阶段；
- 内存占用下降，因为减少了函数对象数量。
五、开发者如何干预
webpack 在生产模式下默认启用该优化，无需额外配置。若需手动关闭（调试阶段），可通过：
js
optimization.concatenateModules = false;强制禁用。此外，保持代码 ESM 化、避免循环依赖、减少动态导入，都能让 Scope Hoisting 覆盖更多模块，进一步放大优化效果。
结语
Scope Hoisting 把"模块隔离"这一历史包袱转化为性能红利，体现了现代打包工具向静态分析与编译时优化演进的趋势。理解其原理与限制，有助于在大型项目中制定更合理的模块拆分与依赖策略，让代码既安全又高效。