您所需要的就是对源语言的所有语义细节进行建模的 AST。根据定义，如果它确实正确地建模了语义，并且您的语言包含三元运算符，那么它也将正确地建模应用运算符的特定顺序（例如，优先模覆盖的结果，例如括号）。
所以你的问题不在 AST 中。它使用优先级不同的类似（三元）运算符生成另一种语言。
这是代码生成中的一个古老问题：目标的运算符与源的运算符不太匹配，因此输出不能是一对一的。在您的情况下，您应该能够通过生成带有括号的 PHP 三元运算符来控制顺序以实现原始语义来解决问题，因此这不是一个大问题。
一般来说，生成实现所需结果的代码序列可能非常复杂，并且有很多方法可以实现。这就是为什么编译器书籍厚而不薄的原因。你似乎已经隐含地选择了“获取 AST、行走 AST、吐出代码”；这几乎是一个即时代码生成器。如果您不关心生成的代码是否特别好，并且目标语言与源语言非常接近，那么这种方法就足够了。
如果代码生成问题更复杂，通常会发生的情况是 AST 用于生成计算的数据流模型，由产生结果的运算符组成，并使用先前运算符的结果，以“运算符”为基础获取变量值和常量。然后遍历数据流表示生成代码；这样做的优点是，您可以在数据流表示中选择一个运算符，在目标语言中找到一个匹配的代码序列，生成它，然后担心如何收集操作数。更好的方案将数据流子图（表示等效的复合目标语言结构）与生成的数据流图相匹配；这可以产生明显更好的代码。通常，可以在生成原始代码后应用目标语言特定的优化来生成更好的代码。在这两种情况下，您都必须担心管理运算符结果；它们可以直接输入到下一个目标语言运算符，还是必须进入某种临时存储（对于机器代码，这可以是另一个寄存器或内存位置）。做这一切并不容易；再说一遍，这就是编译器书籍不薄的原因。
这个想法的一个变体是源到源的程序转换。这将源代码中的构造“直接”映射到目标代码中的构造，尽管这通常是通过操作 AST 在幕后完成的，因为未解析的编程语言文本很难匹配。我们的DMS 软件再造工具包 http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html是这种系统的一个例子。使用这样的工具，您可以用源语言编写模式（隐式匹配解析树），并用目标语言编写相应的模式（隐式生成目标语言 AST）。您可以编写复杂的源或目标构造，从而实现上述数据流图匹配的大部分效果。生成后优化包含更多将目标代码转换为目标代码的重写规则。
底线：只有 AST 还不够，除非您的翻译确实很简单。
您可以在这个 SO 答案中详细了解您需要什么：https://stackoverflow.com/a/3460977/120163 https://stackoverflow.com/a/3460977/120163
警告：强烈的意见随之而来。
关于“转码器”：我更喜欢术语“编译”、“翻译”或“源到源”编译器。我构建程序分析和操作工具已有近 40 年的历史。我从来没有听说过“转码器”这个词，直到我遇到这个问题：将旧版 Cobol/PL1 迁移到 Java 的经验 https://stackoverflow.com/q/1029974/120163恕我直言，一个响应描述了一个名为 NACA 的真正糟糕的代码翻译方案。从那以后我就听说这个词越来越受欢迎。我不明白为什么当我们已经有了完全足够的术语时我们还必须发明另一个术语。通常这是某人发明了高级祭司的标志。 “让我们发明一个闪亮的新术语，这样人们就不会真正理解我们在做什么”。我很高兴把这个词留给如此糟糕的翻译。
