误区一：使用同一种协议，就能查询相同内容
JSON-RPC 规定请求与响应的组织方式，具体能查什么仍由接口方法决定。以太坊开发文档区分执行客户端接口、共识客户端接口和客户端间通信接口，也提示不同客户端的支持情况可能不同。
因此，选择查询技术时，应先明确目标是账户状态、交易记录还是共识信息，再核对相应接口。开发库可以简化调用，但不能据此推断底层节点具备所有查询能力。
误区二：查询最新状态，就等于查询最终确定的状态
以太坊部分状态查询方法接受区块参数。latest、safe、finalized 和 pending 分别表达不同的状态范围，不能视为同义选项。
例如，比较两次余额查询时，需要同时考虑各自使用的区块参数。只保留数值、不记录查询时点，会让差异难以解释。涉及状态确定性的业务，也应明确所需的区块语义。
误区三：有交易编号，任何节点都能找到历史交易
比特币参考文档说明，getrawtransaction 默认主要检索内存池交易；未指定区块哈希时，查询链上交易需要启用交易索引。指定区块哈希时，则要求对应区块可用且包含该交易。
因此，查询失败不能直接证明交易不存在。排查时要区分交易标识是否正确、查询范围是否匹配，以及节点是否具备所需数据和索引。这些条件决定接口能否定位记录。
误区四：十六进制字符串可以统一处理
以太坊接口中的数量和字节数据虽然都采用十六进制编码，格式规则却不同：数量使用紧凑表示，字节数据按每字节两位编码。
解析查询参数和返回值时，应先识别字段类型，再转换内容。把数量的处理规则用于地址、哈希或其他字节数据，可能改变数据表达，导致请求错误或解析偏差。
常见问题：拿到响应后，还需要检查什么
比特币 getrawtransaction 的 verbose 参数会影响返回形式：默认返回序列化交易的十六进制字符串，启用详细输出则返回结构化对象。调用成功并不意味着已经得到可直接展示的业务字段。
检查结果时，应确认返回类型、字段含义和可用条件，再判断它能否回答原始问题。上述方法细节分别适用于对应网络与接口；迁移到其他区块链时，需要重新核对，不能直接套用。