编译器学习：语义分析器构建方案的技术问询

嘿，来聊聊你遇到的这个语义分析的问题——其实这两种方案都可行，而且在实际编译器开发里都很常用，具体选哪种得看你的AST结构和后续的功能规划~

递归遍历AST的方案 #

• 优势：上手门槛极低，尤其是你已经用递归下降实现了解析器，这种思路完全连贯，不需要额外设计复杂的结构。比如你遍历每个AST节点时，直接在节点的处理函数里嵌入语义检查逻辑（比如变量是否已声明、类型是否匹配），逻辑直观，小项目里写起来特别省心。
• 劣势：如果之后AST结构需要频繁改动，或者要添加多种语义分析逻辑（比如类型检查、常量折叠、代码生成），那每个节点的处理函数会变得越来越臃肿，代码会逐渐混乱，维护成本直线上升。不同的分析逻辑混在一起，也很难复用代码。

访问者模式的方案 #

• 优势：完美解决了递归遍历的痛点！它把AST节点的结构和访问节点的逻辑彻底解耦了。你只需要给每个AST节点定义一个accept方法来接受访问者，然后每种语义分析逻辑（比如符号表构建器、类型检查器）都写成独立的访问者类。新增分析逻辑时完全不用修改AST节点的代码，完全符合开闭原则，大型编译器项目（比如Java的javac）大多采用这种方式，扩展性拉满。
• 劣势：初期需要额外的代码结构设计，比如要定义Visitor接口、给每个节点实现accept方法，对于小型项目来说可能有点“重量级”。如果你的AST节点类型特别多，写访问者的实现会有点繁琐，但从长远来看，这种设计会让后续的功能扩展轻松很多。

给你的小建议 #

如果你的项目目前是个小型编译器（比如只处理简单表达式、变量声明），递归遍历完全够用，能快速验证你的语义分析想法；但如果之后打算扩展功能（比如添加类型系统、代码优化、目标代码生成），那尽早重构为访问者模式会让你后续的开发少走很多弯路。我自己一开始写小编译器的时候用递归遍历，后来功能多了就换成了访问者模式，体验差别真的挺大的~

内容的提问来源于stack exchange，提问作者Ady Shlock