误区一：接口统一，各条链就能用同一套解析规则
以太坊执行客户端通过 JSON-RPC 提供数据访问方法；比特币 getblock 则有自己的参数与返回结构。共同使用 RPC，并不意味着方法名称、字段含义和编码规则相同。
跨链读取时，应分别确定查询对象、参数类型和返回结构。通用通信层可以复用，业务字段仍需按对应接口解释。本文讨论的具体规则分别适用于这两类接口，不能直接推广到所有区块链。
误区二：查询最新状态，就获得了固定不变的答案
以太坊状态查询中的区块参数决定读取哪个时点，可区分 latest、safe、finalized 和 pending 等状态。它们表达不同条件，不能混用。
例如，比较两次余额结果时，应先确认是否查询了同一区块。若查询时点不同，结果变化本身不说明接口出错。需要复核的数据，应保留查询所用的区块标识及状态条件。
误区三：带有 0x 的字符串都能当作整数处理
以太坊接口区分十六进制数量和字节数据：数量采用紧凑表示，零为 0x0；字节数据每字节对应两位十六进制字符，空数据可为 0x。
因此，解析前必须识别字段类型。对字节数据随意删除前导零，可能改变数据内容；把空数据当成数值零，也会混淆原本不同的含义。
误区四：查到了区块，就已经拿到完整交易详情
比特币 getblock 的 verbosity 决定返回形式：0 返回序列化十六进制数据，1 返回区块信息及交易标识，2 返回包含交易详情的对象。
如果应用需要交易字段，仅取得交易标识列表还不够。解析逻辑应与请求参数配套，不能默认同名 tx 字段中的元素始终具有相同结构。
误区五：节点有响应，数据就一定满足使用条件
接口能够响应，只能说明请求得到了处理。以太坊提供同步状态查询，但客户端返回的具体字段可能不同。读取结果时，仍需结合节点状态和查询目标判断。
比特币 getblock 的 confirmations 可为 -1，表示该区块不在主链上。因此，“能够查询到区块”和“区块属于当前主链”是两个需要分别确认的问题。
常见问题：结果不一致时先检查什么
先核对网络、查询对象、区块条件及返回详细程度，再检查字段类型和节点状态。只有查询条件一致，结果比较才有明确意义。
开发库可以简化请求编写，但不会消除底层接口的语义差异。排查问题时，应保留原始响应与请求参数，区分数据本身发生变化、请求条件不同和解析错误。