JSON-RPC 错误对象三层码：解析错、参数错与节点私货怎么分层看

一个对象三种出身

JSON-RPC 2.0 规定，调用失败时响应体里放一个 error 对象，最少两个字段：数字的 code 和人类可读的 message，外加一个可选的 data 装补充细节。规范给错误分了三层。最外层是协议级标准码，规范把负三万二千七百六十八到负三万二千整段划给预定义错误：负三万二千七百六十八表示收到了语法坏掉的 JSON，负三万二千七表示请求对象本身缺字段或格式不对，往下依次是方法不存在、参数类型不对、服务端内部故障这几个固定值。这几个码说明请求甚至没走到业务逻辑——多半是你的调用本身就没长对。中间一层留给服务端框架：规范要求负三万二千零九十九到负三万二千之间的号由服务端自己定义，用来表达这台服务器自己的故障语境。剩下中间大片区间归实现自定义，客户端想自造码就填这里。

以太坊类节点怎么落位

以太坊执行层的 RPC 接口沿用了 JSON-RPC 的骨架，但对细节做了实用主义处理。交易被节点拒绝、nonce 太低、Gas 上限超过区块、节点正在同步拒绝广播——这一大类问题通常塞进实现自定义区间，具体数值各家客户端可能不同，真正稳定的信息藏在 message 文本里，排障时读那句话比记数字有用。钱包端的浏览器注入接口则走另一条路，provider 层错误基本都落在实现自定义区段，靠 message 短语区分用户取消、链不匹配、地址未授权这些交互态。理解分层的价值在于知道证据强度：负三万二千七段的错误几乎一定是对接代码的问题，与链状态无关；而自定义码段里的失败往往是网络状态或策略使然，重试或换路径比改代码对症。

message 与 data 怎么配合

规范特意说明 message 只应包含简短文本，任何结构化补充信息应该放 data。好的节点实现在 data 里给回可机读的细节，比如预估失败的具体原因或冲突交易的哈希；差的平台文档则把一切糊进 message。写对接代码的实用准则：先按 code 区间分流，标准码进开发者排障通道，自定义码进用户提示与重试逻辑通道，message 做日志索引的关键字。同一句 too low 在钱包、节点、聚合商三处出现，含义并不自动相同，落点和上下文一起看才作数。

一次排障的分流演示

设想钱包广播交易后弹出一段错误。第一步看 code 的落位：如果落在协议级标准码，先检查调用体是不是缺了字段或参数顺序错了，这与链完全无关；如果落在负三万二千段，多半是节点服务框架层面的自定义故障，换端点或稍后重试合理；如果是实现自定义段，转去读 message——里面出现 nonce 字样就往交易序列方向查，出现 too low 就往费用与余额方向查，出现 header too old 之类的措辞就往节点同步状态方向查。分流顺序反过来，就会把一次简单的链不匹配误判成节点故障，白折腾一小时。

快速问答

问：错误码在不同服务商那里不一样，正常吗？ 答：自定义段本来就允许各实现自由取号，跨服务商稳定的只有协议级标准码那一层。

问：为什么有的接口失败了连 error 都没有？ 答：那是通知型请求，JSON-RPC 允许不返回响应；也可能是网关吞掉了错误，先确认传输层状态码。

常见误区

一是背错误码当背单词，忽略 message 才是节点想说的话；二是把自定义码当跨软件通用的合同，换一家客户端就可能对不上；三是把协议级格式错误误解成链上出了问题，那多半只是你的请求体没拼对。

风险提示：本文为接口协议科普，不构成任何投资建议；具体客户端的码表与语义以其当期官方文档为准。