一、余额不是一个数，是四种信任状态
老式的 getbalance 把能花的钱加成一个数字，问题在于能花和敢花是两回事：别人刚转进内存池的币、矿还没成熟到一百个块的币、来自曾经用过的地址的币，风险各不相同。getbalances 的做法是把钱包可签名的资金拆进 mine 对象下的不同格子，每一格回答一个独立的问题。
二、trusted：确定属于自己的部分
trusted 一格的定义有两条来源：钱包自己创造的输出，以及已经获得确认的输出。前者是你自己花出去又找回来、或本钱包内部转接的钱，后者进了块、进了节点认可的最重链。这一格可以当作放心花的基线——当然，前提是你信任自己连接的这条链。
三、untrusted_pending：别人转来的未确认承诺
untrusted_pending 专门收留他人创建、还躺在内存池里的输出，它和 trusted 的区别在于信任边界：来自钱包自己的未确认花费是自己行为，别人塞进来的未确认输出则是外部主张——父交易可能被替换、整笔可能被双花回滚。文档把它命名为不可信的待确认，意思就是钱包界面若把这一格也涂成绿色可用，等于替用户冒了不该冒的险。脚本消费余额时，稳妥做法是只认 trusted，或按业务风险给待确认一格打折。
四、immature 与 used：两种花钱资格的时间锁
immature 一格来自挖矿产出——coinbase 交易的输出在成熟前无法动用，这是共识层的规则，钱包只是如实上报。用于观察与记账时，把 immature 算进可用余额会导致脚本反复尝试注定失败的花费。used 一格则取决于钱包的 avoid_reuse 标志：设置后，凡是流向曾被花费过的地址的余额都会落在这里，格子本身只在标志开启时出现。它的存在是把地址复用的隐私代价显式化为一个数字，提醒使用者这笔钱在链上已经和旧身份绑在了一起。
五、观察钱包与时间戳
mine 之外还可能有 watchonly 对象，结构类似但没有 used 格——观察钱包只负责数，不负责签。整个结果末尾挂着 lastprocessedblock，标明这些数字是对着哪个区块算出来的。写监控脚本时务必读它：余额与高度不配对，报出的数字就无法归因到链上状态。四格加一栏加一个时间戳，这套结构与其说是接口设计，不如说是把什么时候可以信任余额的答案直接写进了 JSON。
本文内容为钱包接口科普，不构成投资建议。
六、界面与脚本两种消费姿势
钱包界面最省事的诚实做法，是给用户两个数字加一行注释：可用余额等于 trusted 一格，待确认与未成熟分列在旁边，而不是合并成一个看起来随时可花的总数。脚本消费这笔账本时，顺序感比精度更重要：先查 lastprocessedblock 确认快照新鲜，再从 trusted 里选币，untrusted_pending 按业务风险决定是否采信，immature 直接排除在花费计划之外，used 非空时至少要在日志里留一句地址复用的提醒。这些约定写进代码，比在注释里写一段余额是什么的哲学更有用。最后补一句边界：这份账本以这台节点认可的链为真相来源，信任余额之前，先信任你连接的那条链。
七、三个相邻命令的分工
日常还常遇到三个近邻，别拿错工具。getbalance 是旧式的一个总数，适合对账脚本快速估个大概，但它抹平了所有信任层级，严肃场景不如 getbalances。listunspent 逐笔摊开可花输出与确认数，适合看构成、挑硬币，与 getbalances 互为总分表。getwalletinfo 里的未确认余额字段口径更粗，定位是状态概览而不是账本。四者数据源相同、粒度不同，把它们按用途排好，钱包监控脚本就不会出现同一个问题三个数字互相对不上的尴尬——那不是 bug，是你拿平均数回答了一个要明细的问题。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。