误区一：不同链的读取接口可以直接套用
以太坊执行客户端通过 JSON-RPC 提供交互接口；比特币也有自己的 RPC 方法。协议形式相似，不代表方法名、参数与字段含义相同。读取前应先确认目标网络、客户端和接口定义，而不是只替换连接地址。
误区二：查询到的状态都是同一个时间点
以太坊部分状态查询接受区块参数，latest、safe、finalized 与 pending 表示不同状态范围，不能混用。
例如，比较两次余额查询时，应先确认区块条件是否一致。否则，结果不同可能只是读取位置不同，不能据此认定接口出错；待处理状态也不应被描述为已经最终确定的结果。
误区三：带有 0x 前缀就可以按同一种规则解析
以太坊 JSON-RPC 区分数量与字节数据：数量使用紧凑十六进制表示，零写作 0x0；字节数据按每字节两位编码，空数据可写作 0x。
因此，不能统一删除所有字段的前导零，也不能把空数据直接当作数值零。解析规则应由字段类型决定，而不是仅凭字符串外观判断。
误区四：有交易标识就一定能查到历史交易
比特币 getrawtransaction 默认主要查询内存池交易。未指定 blockhash 时，查询已入块交易需要启用 txindex；指定 blockhash 时，则要求目标区块可用且包含该交易。
所以，查不到不等于交易从未存在。应分别核对查询条件、索引配置与区块可用性，避免把节点的数据访问范围误当成整条链的事实范围。
误区五：返回原始数据就等于取得了解析后的对象
在所述比特币接口中，verbose 为 false 或省略时，返回十六进制序列化字符串；设为 true 时，返回交易信息对象。
接收端应明确自己需要原始表示还是结构化字段。把两者混用，容易将正常响应误判为格式异常，也可能导致后续字段读取失败。
常见问题：统一规范是否意味着所有节点表现完全一致
不意味着完全一致。以太坊客户端的接口支持及部分返回字段可能存在差异，具体应核对相应客户端文档。
排查读取问题时，可按网络与客户端、方法与参数、数据可用范围、返回类型的顺序检查。最终说明查询结果时，也应保留必要的区块条件和读取范围，避免给出超出证据的结论。