Trace forensics

从已有的抓取文件得出诊断，由你负责。加载它，整理成能查的形式，缩小到原因，再落到源码上。

和 Runtime forensics 不同，那个是给正在运行的进程加探针。这里抓取的文件已经有了。它是一份固定的数据，读它，不要重跑。工具保持通用，这个 playbook 才能到处用：cpuprofile 和 .json.gz 用 DevTools 或 trace 解析器，spindump 用文本编辑器，heapsnapshot 用你手头的堆分析工具。

认出格式，用合适的工具加载。大文件放在子代理里解析（principle-guard-the-context-window skill），主线程里只留缩减后的结论。
把原始文件转换成能查询的形式。把 trace 或堆快照导进 sqlite，每个采样、栈帧或节点一行。先变成能查的样子，再开始读。
缩小到原因。查出占时间最多的栈帧，顺着调用树走到热路径。查内存泄漏时，从泄漏的对象沿着持有链一直追到 GC root。看 spindump 时，找到卡在 CPU 上或被阻塞的线程，以及它在等什么。
落到源码上。用文件自带的符号，把热点栈帧对应到文件、符号和行号。对不上源码的栈帧，还算不上诊断。把符号解析出来，或者直接说明这份文件里没有符号。
有成对的抓取文件时，拿它来确认。对比改动前后的两份文件。没有的话，把结论标为这份文件能支持的最有力的假设，而不是已确认的原因。
交回一份带出处的诊断，没被要求就不给修法。原因清楚之后，转给 Bug fix 或 Perf issue。吞吐检查点只写一行：throughput checkpoint: n/a, read-only forensics。

回复： 抓取文件和它的格式、缩减后的结论、源码位置、文件路径，以及有没有成对的抓取文件确认过。