给收款地址贴标签这件事，钱包界面做得很顺手：新建收款时写个名字，之后账单按名字归堆。但真要按标签对账——比如给某个客户、某个活动、某台收款机算一个总收入数——图形界面未必给你入口，两条不太起眼的 RPC 才是干这个活的：getreceivedbylabel 和 listreceivedbylabel。本文按 Bitcoin Core v31.0 源码（src/wallet/rpc/coins.cpp 与 src/wallet/rpc/transactions.cpp）核对它们的参数、口径和边界。
两条命令各答一个问题
getreceivedbylabel "label" ( minconf include_immature_coinbase ) 回答”这个标签一共收了多少钱”：返回一个金额数，统计所有带该标签地址收到的、确认数不少于 minconf（默认 1）的交易之和。第一个参数必填，空字符串 "" 代表默认标签——不给任何标签收款时，钱都记在它名下。第二个参数可选，给 0 就能把零确认的收入也计入。第三个参数 include_immature_coinbase 默认关，打开后连还没过 100 块成熟期的 coinbase 收入也一并算进总数。
listreceivedbylabel ( minconf include_empty include_immature_coinbase ) 回答”每个标签各收了多少”：返回一张表，每行一个标签、金额和最近一笔的确认数。注意它和 getreceivedbylabel 的一个参数差异——中间多了一个 include_empty（默认假）。关掉时，一分没收到的标签根本不出现在表里；打开后，所有登记过的标签连零收入也逐条列出，适合做”建了但没人付过”的盘点。
对账口径的四个坑
第一，只算收不算找。统计看的是”付给本钱包带此标签地址的金额”，你自己发给别人的钱、同一笔交易里进你找零地址的钱，都不计入。找零地址如果也贴着这个标签——这种情况在钱包内部是可能出现的——统计会把它当收款地址看待，跨钱包迁移或脚本钱包尤其要留心。
第二，标签不落链。标签存在这台机器的钱包数据库里，链上没有任何字段记录它。换一台机器、换一个钱包文件，除非你迁移或按描述符重建并逐个 setlabel，否则数字归零重来。多人协作的记账别指望标签自动同步。
第三，多地址归组靠标签本身。一个标签背后可能派生过几十枚地址，deriveaddresses 范围内的地址都算数；但如果收款用过了钱包范围之外的地址（比如旧的导入地址），确认数与归属判断会露出缝来，拿 getaddressinfo 逐枚核对是补缝的办法。
第四，重组会影响数字。确认数门槛在重组时可能把”已入账”打回未确认，统计跟着变小。对账脚本把 minconf 至少设成你愿意接受的重组深度，业务上常见做法是 1 到 6 之间自选，并固定住别摇摆。
和邻居命令的分界
getreceivedbyaddress 按单枚地址统计，getreceivedbylabel 按标签聚合，两者一个管点一个管面；listreceivedbyaddress 逐地址列表，listreceivedbylabel 逐标签列表；listlabels 只报标签名单不报金额；listtransactions 则是流水账，颗粒度最细但需要自己加总。真要出一张”按客户维度”的收入表，标签族两条命令是最短路径；要审计到每一笔，才下沉到流水。
实操建议
先跑 listlabels 看名单，再跑一次 listreceivedbylabel 1 true 拉全量表，拿它和 getreceivedbylabel 的单标签查询交叉验证：同一标签两处的金额应该一致，不一致通常说明有地址在标签统计之外。对账窗口固定在同一个高度附近做，避免边重组边统计。标签命名给自己留规则——前缀、日期、分隔符怎么定，写进内部文档——因为三个月后能救你识别度的只有命名纪律本身。
一段最小可用的对账动作
把对账固化成一个固定序列：第一步 listlabels 导出标签全集；第二步对每个标签跑 getreceivedbylabel "标签名" 6，确认数取 6 而不是 1，给重组留缓冲；第三步把加总和钱包 getbalances 的 trusted 项比对——标签体系覆盖所有收款路径时两者应当接近，差值往往指向某个漏贴标签的地址或贴错的找零地址。跑这套动作时把区块高度记进日志，两次对账之间发生过重组，数字的位移就有了解释而不是悬案。标签少的时候手工做就够，标签上百时把序列写进脚本，输出固定成 CSV，人只负责读差异行。
风险提示：本文是钱包记账工具的机制说明，不构成任何投资建议；涉及金额的对外核对请以链上数据与多方记录交叉验证为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。