基于 AST 的自定义代码规则检查器从语法树到团队规范一、正则表达式检查的力不从心团队想禁某类写法第一反应是用 grep。比如不允许直接 print 调试必须走日志。正则能匹配字面却看不懂结构。print可能出现在字符串里、注释里、被调用的方法名里。正则一刀切误伤一片。真正要拦的函数调用它反而认不准。AST抽象语法树才是正解。它理解代码的语法结构能精准定位调用表达式。本文探讨如何基于 AST 写自定义规则检查器。二、AST 检查的运行机制源码经解析器变成树每个节点代表一个语法结构。函数调用是Call节点属性访问是Attribute节点。遍历树匹配特定节点模式即触发规则。与正则不同AST 知道上下文。它能区分字符串里的 print和真的调用 print。这是结构化检查的准确性来源。检查器遍历的关键在访问者模式。对每个节点类型写对应处理逻辑。命中即报未命中则递归子节点。三、生产级检查器实现下面用ast写一个禁用print调用的检查器。import ast from pathlib import Path from dataclasses import dataclass dataclass class Violation: file: str line: int message: str class NoPrintChecker(ast.NodeVisitor): 访问者只拦截真正的 print 调用忽略字符串与注释 def __init__(self, filename: str): self.filename filename self.violations: list[Violation] [] def visit_Call(self, node: ast.Call) - None: func node.func # 精确识别 print(...) 调用而非名为 print 的变量 if isinstance(func, ast.Name) and func.id print: self.violations.append(Violation( fileself.filename, linenode.lineno, message禁止直接使用 print请走日志模块, )) self.generic_visit(node) def check_file(path: Path) - list[Violation]: tree ast.parse(path.read_text(encodingutf-8)) checker NoPrintChecker(str(path)) checker.visit(tree) return checker.violations if __name__ __main__: bad check_file(Path(sample.py)) for v in bad: print(f{v.file}:{v.line} {v.message})真实检查器会支持配置规则列表。每条规则是一个NodeVisitor子类框架统一调度。新增规则只需加类不改主流程。四、边界分析与架构权衡AST 检查准确但有适用范围。语言绑定。每门语言要各自的解析器。Python 用astTS 用typescript库。多语言项目需多套实现成本翻倍。宏与语法糖。某些写法 AST 形态复杂。比如装饰器、上下文管理器规则要专门处理。忽略这些检查就会漏。性能开销。大文件全量遍历有成本。可只对变更文件检查或增量解析。全仓扫描放在预提交或 CI 低频跑。与现成工具的关系。ESLint、Ruff 已覆盖大量规则。自写 AST 检查应只补它们没有的团队特例。不要重复造轮子只补差异化。AST 检查的错误定位友好性决定采纳率。规则报错只给行号不够应附上为什么违规与怎么改的简短说明让工程师一眼懂、立刻修。另一个被忽视的点是规则的可配置性不同团队对同一条规则严松不同规则应支持按项目开关与调参而非硬编码全局。最后检查器自身要被测试用已知违规与合规的样本做回归防止检查器升级后误伤正常代码否则团队会对所有告警失去信任。五、总结基于 AST 的自定义检查本质是用语法结构换准确性。机制上靠访问者遍历节点精准匹配调用等结构。工程上只补通用 linter 缺的团队特例。落地路线先识别需结构化判断的规则写NodeVisitor子类框架统一调度多规则接预提交与 CI。正则看字面AST 看结构团队规范才有了可靠的守门员。