比特币核心开着 -rest 时，多数教程只会告诉你两类端点：按哈希取交易取块。其实路由表里还藏着与内存池直接对话的一对：/rest/mempool/info 与 /rest/mempool/contents。前者吐出内存池的健康指标，后者把整池交易逐单摊平，两个查询参数还能控制返回粒度。本文按 v31.0 源码里 rest_mempool 这个函数的实现，讲清怎么用、能拿到什么、以及一个没有鉴权的端点该注意什么。
端点形状与开关前提
两个端点都挂在 /rest/mempool/ 前缀下，只接受 .json 一种数据格式：请求 /rest/mempool/info.json 得到汇总对象，请求 /rest/mempool/contents.json 得到逐交易结果。源码的路由分发只认 info 与 contents 两个字面量，写成别的都回 400 并附一句期望格式提示；想要求 bin 或 hex 格式也一样落空——实现里 JSON 之外的格式分支直接回”output format not found (available: json)“。前提条件与所有 REST 端点相同：启动时带 -rest，函数入口第一行是预热检查，节点还在加载链状态或索引的阶段，请求会被按”稍后再试”的语义挡回，行为与 RPC 层的预热报错同源。
info：getmempoolinfo 的 HTTP 分身
contents 之外的一半很简单：info 请求直接走与 RPC 同一条序列化函数，返回字段家族与 getmempoolinfo 一致——池内交易条数、占用字节、内存池上限、当前最低进入费率，以及簇时代的费率门槛读数。它把”费市场现在什么行情”压缩成一次不带参数的 GET，监控脚本里连 cookie 鉴权都可以省掉。
contents 与两个查询参数
contents 分支的实现暴露了三个细节。第一，verbose 查询参数默认是 true：默认调用返回的就是 getrawmempool 详细模式那一整本账，每笔交易的费率、依赖、费用、时间一应俱全；显式传 verbose=false 才退回纯 txid 列表。第二，mempool_sequence 参数默认 false，置 true 后结果附带内存池序号——v31 的簇内存池给每笔入场交易发的递增号牌，做”两次快照之间谁进谁出”的对账时，序号比时间戳可靠。第三，两个参数互斥：verbose 与 mempool_sequence 同时为真会被直接拒绝，错误文案甚至写明了出路——想要序号就把 verbose 关掉。这三条组合起来正好覆盖两类用例：要明细就整本拉，要增量对账就拉轻列表加序号，没有第三种混着要的余地。
没有鉴权这件事
REST 面与 RPC 面最大的差异在这里被放大：RPC 的 cookie 或白名单机制一概不管 REST，路由表里也没有鉴权环节。info 与 contents 都是只读的，不会替你把钱动一下；但”谁都能看”在费市场语境下并不完全无害——contents 默认展开全池明细，等于把每台连你 HTTP 端口的客户端看到的交易集合原样奉送，其中包含它们自己的与别人的未确认交易。把它暴露到公网前先想清楚：监听地址收在哪、前面有没有反代限速、要不要干脆只留本机回环。把 REST 端口对全世界打开的节点，等于给自己加了一条透明的行情广播线。
三条实用建议
一是监控用 info：一行 GET 顶一条 RPC 加鉴权样板，容器健康检查里尤其省事。二是同步脚本用 contents 加 verbose=false&mempool_sequence=true，按序号做集合差分，比按时间戳去重稳。三是排查节点被当公共后端时，先翻路由行为——你被谁拉了整池明细，日志里未必留名，但至少可以数一数 8332 上除 RPC 之外还有谁在敲 GET。
与 RPC 面的选择标准
同一份数据两条路，选哪条看三件事。要看逐单明细且需要分页、过滤或字段裁剪，走 RPC——REST 的 contents 一次倾出全池，拥堵时段这一口的字节数不小；只要总量指标且脚本在容器里不想携带 cookie 文件，REST 的 info 更轻；要做毫秒级增量订阅，两条路都不如 ZMQ 推送，轮询 REST 只是把它当仪表盘读数器。三者混用的节点上，把每条路各自的调用频率记进运维文档，比事后从流量里倒推谁在打井要省心得多。
风险提示：本文以比特币核心 v31.0 源码为基准，REST 面行为可能随版本调整，请以实际运行版本为准。内容为技术说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。