trace_ vs. debug_：该选哪个 tracing 命名空间
只要你曾经需要精确知道一笔交易到底做了什么 —— 每一次内部调用、每一处状态变更 —— 你就会撞上这两套 EVM tracing 命名空间。它们重叠到足以让人混淆，又差异到足以造成影响。这是一份实用的地图。
debug_ 命名空间
debug_traceTransaction 与 debug_traceCall 是 geth 原生的。它们会运行一个可配置的 tracer（默认的 struct logger，或 callTracer、prestateTracer 这类内置 tracer），返回操作码级或调用级的细节。callTracer 是主力：它返回完整的内部调用树，含金额、gas 和 revert 原因 —— 这正是大多数应用开发者真正想要的。
trace_ 命名空间
trace_transaction、trace_block 和 trace_filter 源自 OpenEthereum/Erigon。其中 trace_filter 最为突出：它让你能按 from/to 地址在一个区块区间内查询内部调用，而无需自己重放交易 —— 对于追踪资金流向或重建某个地址的活动轨迹极为宝贵。对于这种区间过滤模式，debug_ 里并没有一个干净的对应项。
在两者之间做选择
当你手里有具体的交易哈希、想要它的调用树时，选 debug_ 的 callTracer。当你手里是一个地址或区块区间、想要所有触及它的内部调用时，选 trace_filter。做操作码级的 gas 剖析时，用带 struct logger 的 debug_。所有这些若要对历史区块运行，都需要 archive 状态 —— full 节点只能追踪近期历史。
常见问题
这两套命名空间在每条链上都可用吗？
不是。可用性取决于客户端。基于 Erigon 的节点同时暴露 trace_ 和 debug_；某些 op-stack 及其他客户端暴露 debug_，却没有完整的 trace_ 方法集。请查阅对应链的方法参考文档。
为什么 tracing 比普通调用贵那么多？
tracing 要带着插桩把交易在 EVM 里重放一遍，而历史 tracing 还需要该区块处的 archive 状态。无论是计算还是存储，都比一次简单的当前状态读取要重得多。
相关
充值、拿密钥、上线。
自助开通。支持加密货币或银行卡。按额度计费——重型原语更贵，简单调用很便宜。
获取 API 密钥