ESLint 作为前端工程化中最常用的静态检查工具，其核心价值并不只是统一缩进或引号风格，而是借助抽象语法树（AST）在编码阶段发现逻辑层面的隐患。当代码被解析为 AST 后，每一段语法结构都会变成带有类型的节点，规则通过监听这些节点来判定代码是否合规。
从源码到 AST 的解析过程
ESLint 内部默认使用 Espree 作为解析器，也可以配置为 @babel/parser 或 typescript-eslint 的解析器。解析器接收原始源代码文本，首先进行词法分析，将字符流拆分为 token，随后进行语法分析，按照 ECMAScript 规范生成一棵嵌套的 AST。这棵树以 Program 节点为根，其下包含变量声明、函数声明、表达式语句等子节点。
每个节点都带有 type 字段用来标识种类，例如 VariableDeclaration、FunctionDeclaration、CallExpression 等，同时还记录了起始和结束位置、源码内容等元信息。正因为有了位置信息，ESLint 才能在报错时精准指向某一行某一列，而不是笼统提示文件有问题。
// 示例代码
const foo = 1;
function bar() {
console.log(foo);
}
// 对应 AST 中会出现：
// Program
// - VariableDeclaration (foo)
// - FunctionDeclaration (bar)
// - CallExpression (console.log)
// - MemberExpression (console.log)
规则如何利用 AST 节点做检测
ESLint 的每一条规则其实是一个导出了 create 函数的模块。create 函数接收一个 context 对象，里面包含报告错误、获取源码、作用域分析等 API。函数返回一个映射表，键是节点类型，值是访问该节点时执行的逻辑。当遍历器走到对应节点，就会触发回调。
以最常见的 no-console 规则为例，它并不扫描文本里是否出现 console 字样，而是监听 CallExpression 节点，判断其 callee 是否为 MemberExpression 且对象名为 console。如果是，就通过 context.report 抛出警告。这种基于结构的判断比正则更可靠，不会因为字符串拼接或注释干扰而误报。
module.exports = {
meta: {
type: 'suggestion',
docs: { description: 'disallow use of console' }
},
create(context) {
return {
CallExpression(node) {
const callee = node.callee;
if (callee.type === 'MemberExpression' &&
callee.object.name === 'console') {
context.report({
node,
message: 'Unexpected console statement'
});
}
}
};
}
};
作用域与变量引用的深层检查
单纯看节点类型有时不足以发现错误，比如未定义变量、重复声明等问题需要理解标识符的绑定关系。ESLint 在遍历 AST 的同时，会借助 scope-manager 建立作用域链。规则可以通过 context.getScope() 获取当前作用域，查询某个 Identifier 是否被正确声明。
no-undef 规则就是典型例子。它在 Identifier 节点中检查该名字是否存在于当前或上层作用域的变量集合中，如果找不到绑定且不是全局变量，就判定为未定义。这种检测方式能跨越函数嵌套和块级作用域，准确捕捉手写笔误导致的引用错误。
// 错误示例， ESLint 会报 no-undef
function test() {
return undefVar + 1; // undefVar 未声明
}
编写自定义插件扩展检测能力
当团队有特定业务约束时，可以基于 AST 编写自定义规则插件。例如要求所有 API 请求必须走统一封装的 request 函数，就可以监听 ImportDeclaration 和 CallExpression，禁止直接调用 fetch 或 axios。插件以 npm 包形式发布，命名通常为 eslint-plugin-xxx，在配置文件的 plugins 和 rules 字段中启用即可。
自定义规则同样遵循节点访问模式，区别在于需要更熟悉 AST 结构。可以借助 astexplorer.net 这类在线工具粘贴代码查看生成的节点树，从而确定要监听的 type 和属性路径。写好规则后配合单元测试验证各类正负用例，就能将业务规范固化到 CI 流程中。
// 禁止直接使用 fetch 的简易规则片段
module.exports = {
meta: { fixable: null },
create(context) {
return {
CallExpression(node) {
if (node.callee.type === 'Identifier' &&
node.callee.name === 'fetch') {
context.report({ node, message: '请使用 request 封装' });
}
}
};
}
};
AST 检测的局限与补充手段
AST 静态分析无法得知运行时的真实值，因此涉及动态类型、异步结果分支的问题仍可能漏报。为此 ESLint 常配合 TypeScript 类型检查、Prettier 格式化以及单元测试一起使用。另外，过于复杂的自定义规则会拖慢检查速度，必要时应限定文件范围或采用缓存机制。
总体来看，理解 ESLint 基于 AST 的工作方式，有助于我们理性看待报错信息，也能在团队规范建设时设计出更精准、误报更少的规则，让代码质量保障从被动修复转向主动预防。