把 cmd 当成区块链接口是第一个误区
cmd 或其他命令行工具只是发送网络请求和查看返回结果的载体，真正决定查询内容的是节点提供的 RPC 接口。以太坊客户端通常通过 JSON-RPC 与节点交互，Bitcoin Core 则提供一组 Bitcoin RPC 方法。命令行工具本身不会自动读取区块链，也不能脱离节点地址、端口和接口规范完成查询。
因此，排查查询问题时应先确认三个条件：连接的是哪条链，使用的是哪类节点，以及节点是否开放了对应 RPC 服务。相同的命令行形式只能说明请求外观相似，不能说明 eth_getBalance、getblockcount 等方法可以互换。
误把不同区块链的 RPC 方法当成通用命令
以太坊 JSON-RPC 的方法按用途可以理解为网络传播、当前状态和历史数据等类别。例如，eth_getBalance 用于查询账户余额，eth_getBlockByNumber 用于获取区块信息，eth_getTransactionReceipt 用于获取交易回执。Bitcoin RPC 的方法体系则围绕区块、交易、内存池、网络和钱包等功能组织，例如 getblock、getblockcount、getrawtransaction 和 getmempoolinfo。
这些方法名称、参数结构和返回结果都由具体链及其客户端实现决定。看到一个方法在某条链上有效，并不代表它能在另一条链上使用。查询前应查阅对应客户端的 RPC 文档，并确认节点版本支持该方法。
忽略十六进制格式会导致参数和结果误判
以太坊 JSON-RPC 对数量和未格式化数据采用十六进制表示，但两者的格式要求不同。数量通常使用 0x 前缀和最紧凑的数字表示，零写作 0x0，数量不应带多余前导零。字节数组、地址、哈希和字节码也使用 0x 前缀，但通常要求每个字节对应两个十六进制字符。
这意味着区块高度等数量参数不能简单地按普通十进制字符串传入，也不能把地址或哈希按数量规则处理。返回值中的 0x 前缀也不代表结果异常，读取时应先判断字段的语义，再决定是否转换为十进制或按字节数据解析。
把最新区块、待处理状态和最终状态混为一谈
部分以太坊状态查询方法带有区块参数，例如 eth_getBalance、eth_getCode、eth_getTransactionCount、eth_getStorageAt 和 eth_call。这个参数决定查询的是哪个区块高度对应的状态。latest 表示最新提出的区块状态，pending 表示包含待处理交易影响的待定状态，safe 与 finalized 则分别对应节点认可的安全头和最终确定头。
如果查询时没有明确区块参数，或者在不同时间重复查询 latest，结果可能随新区块产生而变化。查询历史数据时应指定明确的区块编号；比较多个地址或多个合约状态时，也应尽量使用同一个区块参考点，这样结果才具有可比性。
只看查询返回值，却不检查节点状态
节点能够返回结果，并不自动说明它已经同步到预期位置。以太坊提供 eth_syncing 用于了解节点是否正在同步；节点还可能因客户端实现不同而返回不同的同步细节。查询区块高度时，eth_blockNumber 反映的是该节点当前看到的区块高度，不能脱离节点同步状态直接当作全网统一进度。
另一个常见误区是把请求成功与数据正确等同起来。请求成功只表示节点接受并处理了方法，仍需核对网络、区块参数、交易哈希或地址格式。Bitcoin RPC 也包含区块链信息、区块高度、内存池和交易查询等不同方法，具体可用范围还会受到节点运行模式及钱包支持情况影响。
cmd 查询时的实用排查顺序
遇到错误或结果异常时，可以先确认 RPC 请求使用 JSON 格式，并检查请求方法、参数数量和参数类型。随后核对节点地址、端口和目标网络，再确认查询对象属于以太坊账户与合约体系，还是 Bitcoin 的区块与 UTXO 体系。对于历史查询，还要确认节点是否保留所需数据，以及客户端是否支持该方法。
最后，应把返回结果拆成协议字段和业务字段分别理解。JSON-RPC 的请求标识、错误信息和结果字段承担不同作用；交易是否被确认、状态属于哪个区块、节点是否同步完成，都需要结合方法定义和查询参数判断。遵循这一顺序，能够减少因接口混用、格式误读和状态误判造成的排查时间。