一、误以为接口统一就代表能力完全相同
以太坊客户端通过 JSON-RPC 提供统一的交互方式，但具体方法的支持情况仍需核对客户端文档。执行客户端接口、共识客户端接口和客户端之间的 Engine API，也有不同用途。
因此，接口格式相同不等于查询范围相同。遇到不支持的方法，应先确认接口类别与客户端能力，而不是直接认定链上没有相关数据。
二、忽略状态查询对应的区块
以太坊余额、代码和存储等状态查询带有区块参数，可以指定区块高度，或使用 latest、safe、finalized、pending 等标签。这些标签表达不同的查询上下文，不能随意互换。
比较两次结果前，应先确认查询的是否是同一状态位置。否则，即使账户与方法一致，结果不同也未必意味着读取出错。
三、把十六进制字符串按同一种规则处理
以太坊 JSON-RPC 区分数量与字节数据：数量采用紧凑表示，零写作 0x0；字节数据每个字节使用两位十六进制数字，允许保留前导零，空数据可写作 0x。
解析时应先识别字段类型，再决定转换方式。不能为了统一外观而删除所有前导零，也不能把空字节数据直接当成数值零。
四、认为知道交易标识就一定能查到
比特币 getrawtransaction 的查询能力受条件限制：不提供区块哈希时，通常依赖交易位于内存池，或节点已启用交易索引且交易位于链上区块；提供区块哈希时，还要求节点拥有该区块，且交易确实在其中。
所以，“本次查询没有找到”不等于“交易不存在”。排查时应区分定位信息、索引条件与区块可用性，避免把节点查询能力当成全网事实。
五、混淆原始数据与结构化结果
在所述比特币接口中，verbose 为 false 或省略时返回十六进制序列化交易；为 true 时返回包含交易信息的对象。钱包交易则有 gettransaction 这一不同用途的接口。
返回字符串并不代表内容缺失，返回对象也不意味着所有字段始终存在。应用应按照参数与字段条件解析，不能只凭某一次响应固定数据结构。
六、常见问题：怎样判断读取结果是否可比较
先核对网络、接口用途、查询位置与返回格式，再解释数据内容。状态查询重点看区块上下文，历史交易查询重点看定位与可用性。这些检查思路可以通用，但以太坊与比特币的具体方法、参数和限制不能直接套用。