当 webpack 把几百个模块打包进同一个 bundle 时，默认会为每个模块生成一段包裹函数。这些函数在运行期通过 __webpack_require__ 逐个调用，保证了模块作用域互不干扰，却也带来了额外的函数调用开销与体积膨胀。Scope Hoisting（作用域提升）正是为了拆除这道“隔离墙”，让模块内容直接合并进更大的作用域，从而减少函数数量、提升执行效率。

一、隔离墙的诞生

在 webpack 3 之前，所有模块被转译成如下形式：

function(module, exports, __webpack_require__) {
  // 模块 A 的源码
}

运行期通过索引调用这些闭包，相当于在浏览器里模拟 CommonJS 的同步 require。虽然安全，但每多一个模块就多一次闭包创建与调用，CPU 与内存都不讨好。

二、作用域提升的机理

Scope Hoisting 的核心思想是静态分析 + 代码合并。webpack 会在生产模式下启用 ModuleConcatenationPlugin，流程大致如下：

1. 构建依赖图：遍历模块，标记所有导入导出。
2. 闭包消除：将模块代码平铺到同一个函数作用域，同时重命名冲突标识符。
3. 作用域链重构：通过 AST 重写，确保 import/export 语义不变，但不再产生运行时闭包。

最终产物里，原本分散的几十个小函数被“拍扁”成一段连续代码，模块间引用变成普通变量访问，直接去掉一层函数调用栈。

三、启用条件与边界情况

为了安全合并作用域，webpack 要求模块满足：

• 必须是 ESM 格式（import/export 静态声明）；
• 不能出现循环依赖多次引用；
• 不能包含动态导入 import()；
• 不能是 CommonJS 或 AMD 模块。

只要任一条件不成立，当前模块及其子树会回退到传统包裹函数，保证行为一致。

四、收益量化

以典型的中型应用为例，开启 Scope Hoisting 后常见指标：

• 包体积减少 5%～15%，主要节省函数声明与闭包开销；
• 运行时 CPU 占用降低，尤其在启动阶段；
• 内存占用下降，因为减少了函数对象数量。

五、开发者如何干预

webpack 在生产模式下默认启用该优化，无需额外配置。若需手动关闭（调试阶段），可通过：

optimization.concatenateModules = false;

强制禁用。此外，保持代码 ESM 化、避免循环依赖、减少动态导入，都能让 Scope Hoisting 覆盖更多模块，进一步放大优化效果。

结语

Scope Hoisting 把“模块隔离”这一历史包袱转化为性能红利，体现了现代打包工具向静态分析与编译时优化演进的趋势。理解其原理与限制，有助于在大型项目中制定更合理的模块拆分与依赖策略，让代码既安全又高效。

一、引言

历经五年迭代，Webpack 5 于 2020 年 10 月正式 GA，随后在 5.x 的历次小版本中持续交付性能红利与开发体验升级。本文将聚焦五个关键领域：输出清理、顶层 await、体积优化、持久缓存与资源模块，帮助团队无痛迁移并充分理解新版本。

二、输出目录自动清理

在 Webpack 4 时代，开发者需引入 clean-webpack-plugin 以避免旧文件残留。Webpack 5 将这一需求下沉至核心：

module.exports = {
  output: {
    clean: true
  }
}

启用后，每次构建前会递归清空 output.path 目录，确保产物纯净，无需额外插件与脚本。

三、顶层 await

ECMAScript 提案的 top-level-await 允许在模块顶层直接使用 await 语法，Webpack 5 通过 experiments.topLevelAwait 实验开关率先落地：

// src/index.js
const resp = await fetch('https://api.example.com');
export default await resp.json();

配置片段：

module.exports = {
  experiments: { topLevelAwait: true }
}

构建阶段，Webpack 会将包含顶层 await 的模块标记为异步边界，动态生成 Promise 包裹，保持运行语义不变，同时兼容 Tree Shaking 与 Scope Hoisting。

四、打包体积优化再进化

Webpack 5 在模块合并、作用域提升（Scope Hoisting）、Tree Shaking 三条路径上引入更激进的静态分析策略：

• 副作用标记（sideEffects）与导出使用追踪（usedExports）联动，精确剪除未引用代码；
• ConcatenatedModule 算法优化，减少闭包与函数声明数量；
• 嵌套 import() 场景下，公共依赖自动提升至共享 Chunk，避免重复打包。
  实测中型项目体积降幅 8%–15%，冷启动内存占用同步下降。

五、持久缓存

Webpack 4 时代需借助 cache-loader 或 hard-source-webpack-plugin 实现缓存。Webpack 5 默认启用文件系统级缓存：

const path = require('path');
module.exports = {
  cache: {
    type: 'filesystem',
    cacheDirectory: path.resolve(__dirname, 'node_modules/.cache/webpack')
  }
}

首次构建后，模块与 Chunk 的编译结果序列化至磁盘；二次构建仅重新编译变更模块，配合 incremental compilation，二次构建耗时缩短 60% 以上。CI 环境下，将缓存目录挂载至持久化存储，可显著降低流水线运行时间。

六、资源模块：告别 Loader 地狱

Webpack 4 通过 file-loader、url-loader、raw-loader 处理静态资源，配置冗长且版本碎片化。Webpack 5 原生引入 Asset Modules：

• asset/resource：等价于 file-loader，输出独立文件；
• asset/inline：等价于 url-loader ≤ 8KB 内联；
• asset/source：等价于 raw-loader，返回源文件字符串；
• asset：根据体积阈值自动选择 inline 或 resource。

示例：

module.exports = {
  module: {
    rules: [
      {
        test: /\.(png|jpg|gif)$/i,
        type: 'asset',
        parser: { dataUrlCondition: { maxSize: 8 * 1024 } }
      }
    ]
  }
}

原生实现带来零依赖、更小的维护面与更一致的行为语义。

七、迁移路径与实践建议

1. 渐进式升级：保留 Webpack 4 配置主干，逐项启用新特性验证回归。
2. 缓存策略：CI 流水线挂载 node_modules/.cache/webpack，缩短二次构建。
3. 资源模块：逐步移除 file-loader/url-loader，统一使用 Asset Modules。
4. 性能基线：构建前后分别记录产物体积、构建耗时、内存峰值，量化收益。

结语

Webpack 5 以“开箱即用”为核心理念，将过去需要插件介入的能力下沉至核心，既保持了向后兼容，又提供了显著的性能红利。通过合理配置 clean、cache、asset 类型与顶层 await，开发者可在零额外依赖的前提下，获得更快的构建、更小的包体以及更清晰的工程结构。