钱包或脚本报错时，同一句“调用失败”可能来自三个完全不同的层：HTTP 状态码、JSON-RPC 协议错误、钱包接口错误。三套编号各有规范，混在一起看，排查方向会整个跑偏——把报错先归到正确的层，是省时间的第一步。
第一层：HTTP 状态码说的是通道
请求如果压根没被服务端处理，你看到的是 HTTP 层的信号：连不上、超时、网关故障，或者被限流的 429。这一层与链、与钱包都没有关系，只说明“话没送到或对方太忙”。已签发的交易不会因为某个 RPC 网关返回 429 而消失——广播一旦成功，交易就在节点网络里流转，换任何一个可用节点查询都能核实它的状态。
第二层：JSON-RPC 错误码说的是这次调用
通道通了、服务端也确实解析并处理了请求，失败会以 JSON-RPC 2.0 规定的形式返回：响应里带一个错误对象，含整数 code、简短 message，可附带 data。规范预留了一段编号：-32700 Parse error 表示收到的内容不是合法 JSON；-32600 Invalid Request 表示 JSON 合法但请求对象本身不合规范；-32601 Method not found 表示这个节点不支持你调的方法；-32602 Invalid params 表示参数不对；-32603 Internal error 是服务端内部故障。-32000 到 -32099 留给实现自定义的服务端错误，各家节点常常把业务性拒绝塞进这一段。规范还规定成功响应的 result 字段与失败响应的 error 字段互斥，两个都有或都没有都属于实现缺陷。
对普通用户，最常见的是 -32601：比如向一个不支持订阅的节点调 eth_subscribe，或调用较新的方法而节点版本落后，解决办法是换节点或升级，与你的密钥、账户无关。-32602 多半是脚本参数写错，比如区块参数格式不合法。这些码都发生在“链上什么都没发生”的阶段，放心调整重试即可，不存在重复扣款。还有一类容易误解的是 -32000 段的自定义拒绝：节点会把“nonce 过低”“余额不足”“费用过低”这类业务判断塞进这一段，code 相同但 message 天差地别——所以这一段不能按编号查表定性，必须连同 message 与业务语义一起读。
第三层：四位错误码说的是钱包与用户的交互
网页经 EIP-1193 的 Provider 接口调用钱包时，失败用另一套四位码：4001 用户拒绝、4100 未授权、4200 方法不支持、4900 与所有链断开、4901 与请求的那条链断开。注意区分两个“不支持”：4200 说的是钱包不提供这个方法，-32601 说的是节点不提供这个方法——编号位数不同，责任方就不同。同理 4900 是钱包报告它连不上任何链，而 HTTP 层故障只是某一条通道断了。规范还建议：已定稿标准里的方法若不被支持，应以 4200 拒绝，或按该方法自身的规范报错，因此偶尔会看到两套编号在嵌套的错误对象里同时出现。
归层的快速口诀
报错先看形状：三位数负码查节点与参数，四位正码查钱包与授权，HTTP 码查通道与限额。三层可以同时出现——一次 Failed to fetch 下面可能藏着通道问题，一次 JSON-RPC 错误也可能被钱包包装后原样转发。嵌套时以最小括号内的原始错误为准，并拿另一台独立设备或浏览器复现，确认不是本地工具的问题，再决定是换节点、改参数还是补授权。全程记住一条纪律：任何一层报错都不构成你交出助记词或私钥的理由，声称“输入密钥即可修复报错”的引导可以直接定性为诈骗话术。
本文不构成投资建议；错误码处置仅针对技术通道与授权问题，与任何资产价格或收益无关。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。