先明确要查哪类日志
区块链日志的设计文档怎么查，首先取决于“日志”所指的对象。节点运行日志、合约事件和应用侧记录对应不同的文档入口。查阅前应明确：需要了解运行异常、事件字段，还是应用如何保存和解释记录。
本文以以太坊执行客户端接口和 OpenZeppelin ERC20 合约事件为例。相关说明有明确的技术范围，不能直接套用到所有区块链或其他合约实现。
从接口文档定位数据入口
以太坊 JSON-RPC 文档介绍应用与节点交互的统一接口，并将交易回执查询 eth_getTransactionReceipt 列为历史数据方法。该文档主要面向执行客户端，也指向 Execution API 规范；具体支持情况需要核对客户端文档。
查阅接口设计时，可以围绕查询对象、输入参数、返回字段和数据编码建立阅读顺序。接口说明解决数据如何获取的问题；字段代表什么业务行为，还需要与合约定义对应。
从合约文档查事件语义
OpenZeppelin Contracts 5.x 的 ERC20 参考文档列出了 Transfer 和 Approval 事件，并解释相关函数的触发行为。其中，transferFrom 消耗授权额度时默认不发出表示该变化的 Approval 事件。
这说明事件记录的覆盖范围需要结合实现判断。查找设计依据时，应同时阅读事件定义与触发函数说明，关注哪些操作会产生记录、哪些操作可能改变状态却不产生该事件，避免只凭事件名称推断完整业务过程。
把分散说明整理为设计依据
实际查阅可以按接口规范、合约接口、具体实现三个层次展开：接口规范帮助理解数据结构，合约接口说明对外语义，具体实现解释触发条件与例外。三者回答的问题不同，可以相互补充。
整理结果时，记录目标网络、客户端、合约版本和待解决的问题，再为每项结论保留对应文档位置。若是在编写日志采集系统的设计文档，还应明确采集范围、字段解释和遗漏处理方式；这些是应用自身需要定义的内容，不能仅凭底层接口文档认定已经具备。
常见问题与适用边界
找不到名为“日志设计”的独立页面怎么办？相关内容可能分布在 API 参考、事件定义和函数说明中，可以按问题定位章节，不必只搜索“设计文档”这个标题。
看到同名事件，能否沿用其他项目的处理逻辑？还需核对实际合约实现与版本。事件名称只能作为查找线索，不能证明触发条件完全相同。节点接口的可用性也应以所用客户端的说明为准。