Debug Log — Sections & Structure

好，今天我们来看一个非常实用的主题——收件箱日志的格式。这就像是你在调试代码时的一本侦探手册，能帮你定位问题到底出在哪儿。 先看日志的开头，也就是Header部分。它非常规范，上面会清楚地显示你当前用的是哪个API版本，还有这次日志你选择了哪些类别以及它们的日志级别。这个很重要，因为有时候你发现日志里没有你想看的信息，很可能就是这里没选对日志级别。 接下来，你会看到日志里有一些大括号似的标记，比如“EXECUTION_STARTED”和“EXECUTION_FINISHED”。它们就像一个事务的起止点，告诉你整个交易从哪里开始，到哪里结束。知道了这个，你就能分清不同的操作是哪一个请求触发的。 在这个事务内部，又会有一些叫作代码单元的东西，标记是“CODE_UNIT_STARTED”和“CODE_UNIT_FINISHED”。这些代码单元就是一个个独立的工作块，可能是一个触发器（Trigger）、一个工作流规则（Workflow）、一个验证规则（Validation Rule），或者是一个@future方法、甚至是一个批处理。日志会帮你把每个工作块都用这样的小边界框出来，非常清晰。 然后我们再细看每一行日志，它们的格式是管道符分隔的，就像用竖线把不同字段隔开一样，很整齐。每一行都会带着一个精确到微秒的时间戳，格式是“HH:mm:ss.SS + 纳秒”，这样你就能看出事件发生的先后顺序。另外，每一行还有一个事件标识符，告诉你这是一个什么样的操作，比如是SOQL查询、DML操作，还是方法进入退出等等。 还有一个很有用的部分是TypRef，它会帮我们指出当前这段代码是哪个类或者哪个触发器内的。这样你读日志时，一眼就能知道出错的位置在哪儿文件里，非常方便。 日志末尾附近，你会看到一个累积资源使用情况的汇总。它可不是每个代码单元一结束就显示，而是等所有代码单元都跑完了，在事务结束前，统一给出一次累积分析，这样你就能看到这个事务总共消耗了多少CPU时间、查询了多少次数据库等等。 最后，关于堆（Heap，内存使用）的报告也很聪明。如果代码运行过程中没有错误，日志会显示一个“计算出的最大堆”值，告诉你整个过程中内存使用的峰值大概是多少。但一旦有错误发生，日志就会非常准确地报告出错误那一刻实际的堆使用情况，不给你任何估算，这样对查问题特别有帮助。 总结一下，理解收件箱日志这种结构化格式，就像掌握了读心术一样——代码在想什么、做了什么、哪里卡住了，全在这份报告里。希望大家以后在调试时，能像看老朋友写的一封信一样，轻松读懂它。好了，今天的内容就到这里，咱们下节课继续。