Bitcoin Core getbalances怎么对账？

getbalances不是只返回一个“钱包有多少BTC”的数字。它把余额按确认和信任状态拆分，还可包含watch-only视图与钱包处理到的区块位置。对账时若先把所有字段相加，再去猜为什么与业务后台不同，顺序已经反了。

第一步先确认钱包看到了哪个链高

对账记录应同时保存getbalances的lastprocessedblock、节点当前链尖、getwalletinfo的scanning状态和调用时间。如果钱包正在重扫，或它处理到的区块显著落后于节点链尖，当前余额应标成“视图未就绪”，不应立即用作财务差异结论。

余额桶的意思不是“好钱”和“坏钱”

getbalances在mine中区分trusted、untrusted_pending和immature，并可在启用avoid_reuse时报告used相关金额。 trusted一般是钱包当前认为可信的已确认或符合内部信任规则的余额；untrusted_pending表示尚未获得充分确认且不符合可信条件的金额；immature常见于尚未成熟的coinbase产出；开启avoid_reuse时，used字段帮助识别与已重复使用地址相关的余额。

桶	对账含义	常见误解
trusted	钱包视图中可信余额	必然可被业务立即提现
untrusted_pending	待确认且尚不可信	已经丢失或双花
immature	尚未成熟的产出	普通收款的等待确认
used	与avoid_reuse标记相关	链上不存在
watchonly	只监视脚本的余额	节点必然能签名花费

watch-only余额要与密钥控制分开

钱包包含watch-only描述符时，响应可增加watchonly分组，这些输出不等于本节点持有私钥。 watch-only描述符可让节点追踪相关输出，却不证明当前钱包持有签名所需私钥。托管系统常将只读节点用于对账，把签名放在硬件安全模块或离线环境。报表可以显示watch-only资产，但“可观察”和“可支配”必须是两个字段。

安全验收可以随机抽取几个输出，用描述符计算预期脚本，再让真正签名系统证明它能在不暴露私钥的情况下显示或签名指定地址。不要为了对账方便将私钥导入在线节点。

从总额下钻到UTXO明细

listunspent返回可按确认数、地址和安全性筛选的UTXO明细，应用于解释总额与可花费集合的差异。 listunspent可以将总额拆成outpoint、金额、确认数、脚本、描述符与safe等字段。发现getbalances与业务可用额不一致时，应先按同一确认数和安全性规则重建UTXO集合，再叠加内部冻结、提现审批、最小保留额与手续费策略。

确认钱包视图新鲜度
  → 对齐getbalances余额桶
  → listunspent重建UTXO明细
  → 叠加业务冻结与审批
  → 形成可支付或可提现口径

重组、替换和重扫如何处理

短期链重组可让确认数和余额分类发生变化；未确认替换可改变原有交易的可信状态；导入新描述符后的重扫则会逐步发现历史输出。对账系统应保留前后两次快照和对应区块哈希，而不是在数字改变后覆盖旧记录。本页为钱包对账方法，不构成资产可提现或交易建议。

对账结论必须带视图时间

没有lastprocessedblock、链尖、钱包扫描状态和采集时间的余额截图，只是一个无法复现的数字。对外报告前要先固定这四项。

本文的三个可复核核心是：

getbalances在mine中区分trusted、untrusted_pending和immature，并可在启用avoid_reuse时报告used相关金额。
钱包包含watch-only描述符时，响应可增加watchonly分组，这些输出不等于本节点持有私钥。
listunspent返回可按确认数、地址和安全性筛选的UTXO明细，应用于解释总额与可花费集合的差异。

目前仍需保留的边界：业务层的“可提现余额”还受内部冻结、批准和风控规则影响，RPC本身不提供这个业务口径。

可结合listunspent筛安全UTXO、lockunspent冻结UTXO、listdescriptors审计继续查看相邻知识。本文为信息与技术教育内容，不构成投资、交易或法律建议；涉及资产或系统变更时，请先在隔离环境验证并自行承担风险。