写代码或者设计语言解析器时，经常会遇到一句话能被理解成多种意思的情况。比如自然语言里的‘我看见了她拿着望远镜’，是我在用望远镜看她，还是我看到她手里拿着望远镜？编程语言里也类似，表达式 a + b * c 到底先算加法还是乘法，就得靠语法规则来定。
语法树长什么样
语法树（Parse Tree）是把一段代码或句子按语法规则拆解后的结构化表示。每个节点代表一个语法成分，比如表达式、语句、变量等，根节点是整个程序或句子，叶子节点是具体的词或符号。
比如表达式 a + b * c，如果乘法优先，语法树会把 * 放在更深层，+ 当作上层操作；如果加法优先，结构就反过来。树的形状直接决定了计算顺序。
什么时候会出现歧义
当同一个句子能生成两棵或多棵不同的合法语法树时，就说明语法有歧义。比如下面这个简单的文法：
E -> E + E
E -> E * E
E -> id面对输入 id + id * id，系统可以先归约 + 或先归约 *，结果得到两种结构。一种是 (+) 的左子树是 id，右子树是 (*) 节点；另一种是 (*) 的右子树挂了个 (+)。这两种结构对应不同的运算优先级，也就意味着不同的执行结果。
怎么发现这种问题
最直接的办法是让解析器尝试生成所有可能的语法树。如果输出不止一棵，那就有歧义。像 GLR 或 Earley 这类解析器能处理不确定路径，它们会在分析过程中保留多个分支。一旦发现最终能走到多个完整结构，就能报告歧义存在。
另一种方式是在文法层面检查。比如使用工具 YACC 或 Bison，它们在生成解析表时会提示“移进/归约冲突”或“归约/归约冲突”。这些冲突本质上就是语法无法决定下一步该怎么走，背后往往对应着歧义结构。
实际开发中的应对
在做 DSL（领域特定语言）或配置文件解析时，很多人一开始图省事，写个简单文法就上线。结果用户一写复杂表达式，解析结果和预期对不上。这时候回过头看语法树，才发现同一句话被拆出了好几种结构。
解决办法通常是显式引入优先级和结合性规则。比如告诉解析器 * 的优先级高于 +，+ 是左结合。这样即使文法本身允许多种展开，解析器也能根据附加规则只保留一棵树。
还有一个办法是重写文法，把优先级融入结构中。比如不再让 E 直接推出 E + E，而是分层设计：Expr → Term + Expr | Term，Term → Factor * Term | Factor。这样一来，* 自然被限制在 Term 内部，+ 在外层，优先级就固定了。
语法树不是用来展示好看的东西，它是决定程序怎么跑的关键结构。只要一棵输入能对应多棵树，执行逻辑就不确定。在做编译器前端或解析模块时，盯着语法树看几眼，往往比跑测试更容易发现问题根子在哪。