Pratt 解析是黑盒？9 行代码背后的真相与反直觉

Pratt 解析的核心：9 行代码的算法

我在去年开始写一个编译器，骨架用了大量基于 Pratt 的解析机制。当时我并没有细究那段核心代码，只是照着教程抄了一遍，就继续往下写了。直到前几天读到一篇博客，我才意识到自己当时的行为在传统观念里有多么不靠谱。文章里说，Pratt 解析的核心算法在高阶语言里只占 9 行 Rhombus 代码 来源：vinipsmaker。

这 9 行代码确实简洁。一个 expression 函数，通过 token 的 nud 和 led 方法，把表达式解析的逻辑浓缩成一个循环。大部分 Pratt 教程花全部时间解释这个算法怎么运转，怎么处理运算符优先级，怎么绑定力，却几乎不解释算法背后真正重要的属性 来源：vinipsmaker。

这让我有点困惑。如果算法本身才是教程的重点，那背后的属性又是什么？文章给出的答案出人意料：那 9 行代码恰恰是整件事情里最不重要的部分 来源：vinipsmaker。

反直觉：理解实现并非使用前提

作者的观点很直接：你不需要理解这 9 行代码就能使用 Pratt 解析。这个说法乍听违背直觉，但他给的类比很有说服力。如果你只有理解了快速排序的实现才能使用快速排序，只有从零实现了文件系统才能读写文件，那计算机科学几乎没法推进。因为整个领域建立在这种抽象能力之上 来源：vinipsmaker。

我回头想自己去年写编译器的经历，正是这个道理。我依赖 Pratt 机制构建了编译器的骨干，但对那段代码的理解停留在复制粘贴层面。没有遇到大坑，也没有回头补课。作者甚至断言，缺乏抽象能力的人在计算机科学领域将一事无成。这话说得重，但我倾向于认同。我们每天使用的工具，从操作系统到编程语言，有多少是真正理解内部实现的？

传统解析技术其实早就承认了这一点。编译器编译器，比如 Yacc 这类工具，用代码生成器吐出解析算法，因为只有极少数人愿意花时间学解析引擎的工作原理 来源：vinipsmaker。Pratt 解析和它们没有本质区别，只是 Pratt 足够小，小到你可以直接复制那 9 行代码到项目里，不用引入一个新依赖。这个算法从 1973 年到现在没有变过，以后也不会变 来源：vinipsmaker。

与传统编译器编译器对比及多源验证

那篇博客在 Hacker News 上的反响极其冷清，只有 1 分、0 条评论 来源：HN。我看了下时间戳，帖子是 2026 年 4 月发的，按说 Pratt 解析不算冷门话题，这个数据有点反常。一种解释是作者的观点太反主流了。他说的“不必理解实现就能用”跟大多数教程的叙事相悖，可能引起不了讨论，因为人们更倾向于关注算法本身，而不是抽象思维。

我倾向于认为，冷清恰恰印证了文章的主题。开发者对 Pratt 内部机制的关注度有限，更多人只是把它当作一个黑盒，能跑就行。这跟编译器编译器的逻辑如出一辙：没人因为不懂 Yacc 内部原理就觉得不好意思。作者用“黑盒”做标题，大概就是想戳破一层窗户纸。

当然，我不能说这个数据就代表所有开发者。1 分和 0 条评论可能只是 HN 的抽样偏差，也可能是帖子发布时机不佳。我不确定。但有一点是明确的，作者对传统解析方式的观察站得住脚：解析算法本身确实可以是一个无需深究的黑盒，前提是你理解了它背后的抽象模式。

我对 Pratt 解析的态度，从去年开始写编译器时的“照抄就行”，到现在读完这篇文章，变得更坦然了。理解 9 行代码的细节当然有用，但更重要的问题是：我能不能在其他地方复用这种抽象？如果答案是肯定的，那这 9 行代码确实不是重点。

原文：

Pratt parsing is a black box · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年11月2日