如果要弄清楚为什么 Webpack 打包后的代码会出现模块编号、变量名被压缩、未引用的导出被移除，就需要回到构建流程的起点。Webpack 并不是对源码做简单的字符串查找替换，而是先把 JavaScript 文件交给解析器生成一棵抽象语法树，后续的依赖收集、代码转译和优化基本都在这棵树上完成。抽象语法树通常简称为 AST，它以节点形式描述代码结构，比如变量声明、函数调用、条件分支、导入导出都有对应的节点类型。

下面围绕解析、遍历、转换、生成四个环节来说明 Webpack 中的 AST 工作方式，并通过一个最小示例演示如何操作这棵树。

Webpack 如何把源码解析成 AST

在 Webpack 5 中，JavaScript 模块的默认解析器是 acorn。它读取文件内容后先做词法分析，把连续的字符拆成 token，例如 const、name、等号和字符串值；随后进行语法分析，根据 JavaScript 语法规则把这些 token 组合成有层级关系的节点。最终得到的 AST 遵循 ESTree 规范，常见的节点包括 VariableDeclaration、Identifier、CallExpression、ImportDeclaration 等。每个节点都带有 start、end 等位置信息，方便后续生成 source map。

解析过程本身并不关心业务语义，只判断代码是否符合语法。比如下面这段简单的入口代码：

import { add } from './utils';
const total = add(1, 2);
console.log(total);

解析后可以理解为包含一个 ImportDeclaration 和两个语句节点。Webpack 内部的依赖收集插件会遍历这棵树，当遇到 ImportDeclaration 节点时读取 source.value 得到 ./utils，然后创建依赖关系并继续解析该模块。如果源码中使用动态 import()，则会遇到 CallExpression 节点且 callee 是 Import，Webpack 会将其拆分为单独 chunk。

这里有一个容易忽略的细节：AST 节点是树状结构，一个节点下面可以挂多个子节点。修改父节点时，子节点和位置信息不会自动更新，因此生产级工具通常重新生成节点或使用专门的遍历器来处理父子关系。理解这一点对编写 Plugin 或 Loader 时避免产生无效 AST 很重要。

Loader 阶段如何基于 AST 完成代码转换

Webpack 的 Loader 管道接收的是源码字符串，每个 Loader 可以返回字符串或 Buffer。像 babel-loader、ts-loader 这类转译型 Loader 内部并不是做正则替换，而是先把当前文件解析成 AST，再根据配置修改节点，最后调用代码生成器把 AST 还原为字符串。这样做的好处是可以保留语法结构，处理复杂转换时不容易破坏原有代码。

以箭头函数转换为例，babel-loader 在 AST 中遇到 ArrowFunctionExpression 节点，会将其替换成 FunctionExpression，同时处理 this 作用域和 arguments 对象。这个操作如果靠正则表达式完成，就必须穷举各种写法，容易漏掉注释、嵌套函数或异步箭头函数。AST 转换的优势在于节点类型是确定的，转换规则可以作用于所有符合类型的节点。

除了 Loader，Plugin 也可以间接使用 AST。Webpack 的模块对象在构建阶段可能保留着源码和 AST，DefinePlugin 会替换代码中的全局常量，Tree Shaking 则依赖 ES 模块的静态结构进行检查。它们通常通过 Webpack 暴露的 compiler 或 compilation 钩子介入，而不是直接给每个文件做转译。两者定位不同：Loader 解决单个文件的语法转换，Plugin 解决整个构建流程中的资源优化和打包策略。

自定义 Loader 时，如果只修改少量字符，直接处理字符串是可行的；但一旦涉及语法结构变化，例如将某个函数调用改写为另一个表达式，就应该使用 @babel/parser、@babel/traverse 和 @babel/generator 这一组工具。下面第三节会给出完整示例。

动手实现一个最小 AST 转换工具

要直观理解 AST 的转换，可以不依赖 Webpack，直接在 Node.js 脚本中完成解析和生成。需要安装 acorn、acorn-walk 和 escodegen 三个包，或者使用 Babel 系列工具。下面以删除 console.log 为例，展示如何遍历并修改 AST。

const acorn = require('acorn');
const walk = require('acorn-walk');
const escodegen = require('escodegen');
const source = `
function add(a, b) {
  console.log('adding');
  return a + b;
}
`;
const ast = acorn.parse(source, { ecmaVersion: 2020 });
// 遍历时删除 ExpressionStatement 中属于 console.log 的节点
walk.fullAncestor(ast, (node, ancestors) => {
  if (
    node.type === 'CallExpression' &&
    node.callee &&
    node.callee.type === 'MemberExpression' &&
    node.callee.object &&
    node.callee.object.name === 'console'
  ) {
    const parent = ancestors[ancestors.length - 2];
    if (parent && parent.type === 'ExpressionStatement') {
      // 将表达式替换为空语句，避免破坏结构
      parent.expression = {
        type: 'Literal',
        value: 0,
        raw: '0'
      };
    }
  }
});
const output = escodegen.generate(ast);
console.log(output);

这段代码先调用 acorn.parse 得到 AST，再用 acorn-walk 的 fullAncestor 遍历每个节点，并通过 ancestors 数组找到当前节点的父节点。对于 console.log，其父节点是 ExpressionStatement，我们把 expression 替换为一个 Literal 节点，最后用 escodegen 生成字符串，得到 0; 代替 console.log。虽然直接生成 0; 不太优雅，但已经能说明节点替换的完整链路。

更实用的做法是使用 Babel 系列 API。@babel/traverse 提供了访问者模式，enter 和 exit 回调中都能拿到 path 对象。path 封装了节点关系，调用 path.remove() 可以直接删除当前节点，调用 path.replaceWith() 可以替换节点，内部会自动处理父节点引用。下面是一个将 console.log 调用整体移除的例子：

const parser = require('@babel/parser');
const traverse = require('@babel/traverse').default;
const generate = require('@babel/generator').default;
const code = `
function add(a, b) {
  console.log('adding');
  return a + b;
}
`;
const ast = parser.parse(code, {
  sourceType: 'module'
});
traverse(ast, {
  CallExpression(path) {
    const callee = path.node.callee;
    if (
      callee.type === 'MemberExpression' &&
      callee.object &&
      callee.object.name === 'console'
    ) {
      path.remove();
    }
  }
});
const output = generate(ast).code;
console.log(output);

在自定义 Loader 中，我们可以把上面这段逻辑包进 module.exports 函数，接收 source 并返回 generate(ast).code。Webpack 会把 Loader 的返回值继续交给后续 Loader 或进入模块解析流程。需要注意的是，如果 Loader 返回了 AST，Webpack 也可以直接使用，但大多数情况下返回字符串更通用，避免与后续 Loader 的输入类型冲突。

AST 带来的构建性能问题与优化方式

AST 的生成和遍历需要消耗 CPU 资源，项目变大后解析阶段往往会成为构建时间的瓶颈之一。Webpack 默认会缓存模块解析结果，当文件未发生变化时跳过重新解析。开发环境还可以配合 cache-loader 或 Webpack 5 内置的持久化缓存，把 AST 相关信息写入磁盘，加快二次构建。

除了缓存，另一个思路是减少重复解析。比如 ts-loader 和 babel-loader 同时使用时，不要让两者都完整解析同一份代码。可以在 ts-loader 中开启 transpileOnly，再交给 babel-loader 做语法转换，避免 TypeScript 编译器做完整类型检查和 AST 转换带来的额外开销。线程级别的并行解析则可以通过 thread-loader 实现，但它对 AST 转换类 Loader 的效果取决于任务规模和通信成本。

Tree Shaking 也会受 AST 结构影响。如果模块里存在副作用，Webpack 在标记未引用导出时会更保守。通过 package.json 的 sideEffects 字段或 optimization.sideEffects 配置，可以帮助 Webpack 更准确地判断哪些代码可以安全移除，减少后续代码生成阶段的 AST 规模。压缩工具 terser 同样基于 AST 工作，它在压缩阶段会重新解析代码，因此合理配置 minimize 和 parallel 可以平衡产物体积与构建耗时。

总结来说，AST 在 Webpack 中并不是某个单独插件的私有实现，而是贯穿模块解析、Loader 转换、Tree Shaking 和代码压缩的基础数据结构。掌握它的解析、遍历和生成过程，有助于定位源码与产物不一致的问题，也能为编写更高效的构建配置提供依据。