ESLint 的 no-console 规则默认仅检测直接调用（如 console.log），对别名赋值（const c = console）、解构（const { log } = console）和动态执行（eval("console.error()")）无感知，需自定义规则通过 AST 遍历、作用域追踪与轻量数据流分析覆盖这三类逃逸路径。
为什么 ESLint 的 no-console 规则有时“不生效”
不是规则没起作用，而是它默认只检查 console.log 等直接调用，对 const c = console; c.warn()、eval("console.error()") 或解构赋值如 const { log } = console 无感知。ESLint 基于 AST 分析，但它的标准规则不追踪变量别名或动态访问——这正是需要自定义规则的起点。
真实项目里，开发者绕过 no-console 的方式往往就这三类：别名赋值、属性解构、字符串动态执行。静态分析必须覆盖这几种 AST 模式，否则提醒形同虚设。
如何写一个能识别 console 别名和解构的 ESLint 自定义规则
核心是遍历 AST 中的 MemberExpression 和 Identifier 节点，并向上回溯作用域与变量声明来源。不能只看节点表面，得做“数据流分析”的轻量版。
- 在
CallExpression中捕获所有调用，检查node.callee是否为MemberExpression（如c.log）或Identifier（如log） - 对
MemberExpression，判断node.object.name === "console"；若不是，用context.getScope().variables查该object是否指向console的声明 - 对解构场景（
const { warn } = console），需监听VariableDeclarator，当init.type === "MemberExpression"且init.object.name === "console"时，把id.name（如warn）记入当前作用域的“已知 console 别名表” - 注意：ESLint 的
scope.set不可写，要用闭包缓存每个作用域的别名映射，配合scope.upper向上查找
console 动态访问（eval、Function 构造器）怎么处理
严格来说，AST 静态分析无法 100% 覆盖动态字符串执行。但可以拦截高风险模式，降低漏报率。
- 匹配
CallExpression中callee.name为"eval"或"Function"的节点，再检查arguments[0]是否为Literal字符串，且内容包含"console."或"console[" - 对
TemplateLiteral类型参数，不展开求值，但若模板中存在console字面量 + 插值（如`console.${method}()`），也应告警——此时插值变量不可控 - 不建议尝试解析
eval内部字符串为 AST（成本高、易错），聚焦“明显危险信号”更实际
性能和误报之间怎么平衡
深度作用域追踪和跨作用域别名映射会拖慢 lint 速度，尤其在大型项目中。关键不是“全查”，而是“查得准”。
- 跳过
node.parent.type === "MemberExpression" && node.parent.property === node这类冗余路径，避免重复分析同一调用链 - 别名映射只在函数作用域（
FunctionExpression/ArrowFunctionExpression）内维护，全局作用域别名极少且易管理，不必过度建模 - 对
console的非方法访问（如console.xxx）默认不报错，除非明确配置allowProperties: false—— 大多数团队只关心方法调用 - VS Code 中 ESLint 插件默认启用
lintOnSave，规则响应必须控制在 200ms 内，否则编辑体验明显卡顿
真正难的不是写出能跑的规则，而是让规则在不增加开发者等待时间的前提下，守住那些容易被忽略的别名逃逸路径。一旦放行一次 const c = console，后续整个函数都可能成为盲区。
