核验要落实到具体结论
对接区块链系统的资料来源如何核验，关键是让每一项接口判断都有对应依据。资料来自哪里、描述哪类接口、适用于什么客户端、是否覆盖当前运行条件，需要分别确认。网页标题或方法名称只能帮助定位，不能单独证明接口在目标系统中可用。
两个来源分别能证明什么
ethereum.org 的 JSON-RPC 文档说明，应用通过节点与以太坊交互，并区分执行客户端接口、共识客户端接口及客户端间通信的 Engine API。它还提示，具体 API 支持情况需查对应客户端文档。因此，核验时必须先确定接口所属范围。
developer.bitcoin.org 的 RPC 参考目录按区块链、网络、钱包等用途列出方法，并注明钱包 RPC 依赖 Bitcoin Core 的钱包支持构建条件。这个目录可用于定位方法类别，但不能仅凭目录确定完整参数或目标版本的支持情况。
这两个来源描述不同系统，适合共同说明核验思路，不能互相证明某个具体接口的行为。核验同一技术结论，仍需寻找针对该系统的规范和实现依据。
把出处与适用条件一起记录
核验记录宜包含来源域名、页面路径、对应章节、待确认结论，以及适用的客户端和版本。对于缺少版本信息的页面，应保留这一不确定性，继续查找与目标实现匹配的说明。
引用链也需要清楚：介绍页用于理解概念，规范用于确认协议要求，客户端文档用于确认实现差异。第三方封装库的使用说明还需对应到底层接口，避免把库提供的方法直接当作节点原生能力。
核对参数语义，避免误读示例
核对接口时，应逐项关注参数类型、编码规则、返回结构和查询上下文。以太坊文档区分十六进制数量与字节数据，并说明区块参数影响状态查询所对应的位置；忽略这些区别，可能使表面相似的请求表达不同含义。
示例中的客户端版本、网络编号或返回值只能用于理解格式。它们不能证明目标节点当前处于相同环境，也不能替代针对实际配置的核对。
常见问题与核验边界
文档列出方法，是否就能直接使用？还需确认客户端实现和启用条件。两个网站都提到 RPC，是否足够相互印证？只能说明它们都涉及远程调用，具体方法仍须分别核验。
文档与实际响应不一致时，应先检查版本、配置、参数及查询条件，再判断差异来源。一次请求成功只能支持该环境下的观察结果；可复核的结论还应保留请求条件与响应证据，明确哪些内容已确认、哪些仍待验证。