一个错误页面，告诉你确切的行号，而不是猜测。

通过编译或转译代码的堆栈跟踪是一种熟悉的无用情况：行号是真实的，但它指向的是没有人手动编写的生成输出，距离你实际需要查看的源代码相差甚远。Phlo 的错误页面则指向源代码，因为解析器的构造使得这一点成为可能。

为什么这能工作

基于行的解析器（没有 AST，在之前的帖子中讨论过）意味着 .phlo 文件中的第 N 行直接映射到生成的 PHP 中的已知行。这不是事后附加的调试功能，而是直接源于编译器的工作原理：因为没有复杂的标记化步骤重新排列结构，源行到输出行的映射保持简单，足以记录和使用。

你实际看到的

生产错误显示一个简短、可引用的 8 字符引用 ID，既出现在用户看到的错误页面上，也出现在前端调用返回的 JSON 或异步负载中。相同的 ID 被记录到 data/errors.json 中，包含真实的细节：哪个 .phlo 文件，哪一行，异常是什么。用户报告该 ID，开发者进行 grep 搜索，确切的失败信息就在那儿，无需从模糊的描述中重建“哪个请求，大致何时，可能在那个区域”。

static errorPage($code, $id, $msg = null) => DOM('<main class="oops"><h1>Something broke.</h1><p>Reference: '.$id.'</p></main>')

错误管道也是递归保护的：如果渲染器本身或自定义的 errorPage 抛出错误，它会回退到一个无依赖的简单页面，而不是在第一次错误的基础上循环进入第二次失败。

更深入的需求

对于仅凭引用 ID 无法解释的情况，追踪模式（在开发入口点中设置 trace: true）提供请求级别的追踪：每次对生成的方法、prop 获取器或原生助手的调用都会记录时间和参数到 data/trace/<id>.json，可以从 Phlo Control Center 的 Trace 选项卡中读取。这是升级路径，大多数情况下，文件、行号和引用 ID 足以直接找到修复；追踪用于当失败与顺序和时机有关，而不是单一的错误行。

共同的线索

这是在本网站其他地方出现的相同设计选择：在破损的事物与试图修复它的人之间减少层次，无论这个人是在终端的开发者还是以编程方式读取相同错误的代理。