一次请求发多条命令：比特币节点 RPC 的批量数组与通知规则 图 1
一次请求发多条命令：比特币节点 RPC 的批量数组与通知规则 · 图 1

在日常运维里，很多比特币节点操作员只用过一种 RPC 调用方式：bitcoin-cli getblockcount，一条命令一次连接。但比特币核心的 RPC 服务其实支持另一种发送形态——把多条请求装进一个 JSON 数组，一次 HTTP POST 全部交给节点。bitcoin-cli 自己的 -getinfo 就是靠这个机制拼出来的：它并不存在对应的服务器端命令，而是客户端把 getnetworkinfo、getblockchaininfo、getwalletinfo、getbalances 四条请求打包成批量请求发出去，再把回包按编号拼成一个仪表对象。这篇文章按 v31.0 源码讲清批量请求在服务器端的真实行为：鉴权在什么时点做、错误怎么回、通知为什么收不到回复，以及监控脚本怎么利用这些规则。

批量请求的入口判定：对象走单条，数组走批量

节点收到 HTTP POST 后，先解析请求体。判定顺序很直接：请求体是 JSON 对象，按单条请求处理；是 JSON 数组，按批量处理；两者都不是，直接回 Invalid Request 类错误。批量的执行方式是一个顺序循环——从数组第一个元素开始逐条解析、逐条执行，把每条的应答按顺序追加进一个数组回包。也就是说，批量请求里的命令是串行执行的，不存在并行调度：前面一条命令在等锁或者跑长任务，后面的命令就得排队。指望”打包发出就并行执行”是对批量最常见的误解，批量省下的只是 HTTP 往返和连接建立的成本，不是节点内部的执行时间。

一次请求发多条命令：比特币节点 RPC 的批量数组与通知规则 图 2
一次请求发多条命令：比特币节点 RPC 的批量数组与通知规则 · 图 2

回包顺序与”id 不是排序键”

回包数组的顺序等于数组元素的执行顺序，而不是按 id 归位的顺序。JSON-RPC 2.0 规范本身允许服务端乱序回包，所以严谨的客户端应当按每条应答里的 id 做关联，而不是假设”我第三条发出就第三条回来”。比特币核心恰好是顺序回包的实现，但只要中间夹了通知（无 id 的请求），顺序就会发生视觉错位——通知不产生应答，不占回包位置。于是”回包第 N 条对应请求第 N 条”的朴素映射在混用通知的批量里必然出错。对账脚本里最稳的做法是每条请求给一个批次内唯一的数字 id，收到回包后按 id 建表再消费。

单条请求与批量请求的错误哲学完全不同

这是源码里最值得注意的分支。单条请求在旧版 JSON-RPC 1.x 语义下出错时会直接抛异常，客户端可能拿到 HTTP 层的非 200 状态；而批量请求内部的所有异常都被逐条捕获，编译成带 error 字段的应答对象放进回包，整个 HTTP 响应始终是成功状态。源码注释写得很直白：批量永不返回 HTTP 错误，全部塞进”HTTP OK”里。这带来一个实际后果：如果你的脚本用 HTTP 状态码判断”这批命令成没成功”，批量路径下永远绿。正确姿势是逐条检查回包数组里每个元素的 error 字段是否非空。另外要注意 id 的一个坑：处理批量回包的工具函数要求每条应答的 id 小于批量长度，这是拿 id 当数组下标用的实现约束，所以批量内的 id 应当从 0 开始取整数，别用 UUID 或者全局递增的大数。

通知：执行但不回复

JSON-RPC 2.0 定义了一种没有 id 字段的”通知”请求：只发出意图，不期待应答。比特币核心忠实实现了这个语义——通知会被真实执行，但服务器写回的是一条无内容的响应（单条通知回 HTTP 204 类空响应，批量里的通知直接从回包数组里缺席）。源码里对全通知批量的处理还有一段注释权衡：按规范空批量也该回空，但实现选择按自己收到的内容处理。对运维来说真正要记住的是安全面：通知”没有回复”不等于”没有执行”，把写操作的 RPC 以通知形式发出去，你只是放弃了确认回执，节点该改的状态一样会改。除非明确不需要结果，不要用通知发写命令。

鉴权发生在执行之前，白名单对批量逐条审

如果节点配置了 RPC 白名单，批量请求会被逐条拆开检查方法名，任何一条越权，整个请求直接以 403 拒绝——不是跳过越权条目继续执行其余部分，而是整批不执行。单条请求的白名单检查在解析出方法名之后执行，批量则在进入执行循环之前就完成全部检查。这个”先审后跑”的设计让批量没法被用来绕过白名单做探测。另一个固定前提：RPC 只接受 POST，GET 会直接收到方法不允许的回复；认证失败时服务器还会在回前故意停顿一小段时间，作为对暴力撞库的减速措施。

实操清单

给监控与对账脚本的正确用法收个尾：一次要取多条独立状态时用批量，连接数与延迟都能省；批量内的 id 用从 0 开始的整数；回包按 id 关联而不是按位置；逐条查 error 字段而不是只看 HTTP 状态；不在批量里混通知，除非你确切知道自己在做什么；有超时长任务时把慢命令单独发，避免它把同批的轻量状态查询全部拖过客户端超时。批量是好工具，但它改变的是打包方式，不是执行模型，也不是安全边界。

风险提示：本文描述的是节点接口机制与运维知识，不涉及任何资产操作与收益安排；RPC 端口暴露与账户安全相关操作请先阅读官方文档的权限章节，本文不构成投资、配置或买卖建议。