修剪节点找回一笔收款：importprunedfunds 与交易证明的配对入库

修剪钱包的视觉盲区

为了压缩磁盘占用而开启修剪（prune）的节点，会丢弃较旧的原始区块文件。磁盘省下了，代价是钱包对老交易失忆：重扫（rescan）依赖区块流，区块都不在了，扫到某个高度就只能停住。如果一笔收款正好落在这段盲区里——哪怕你的地址分文未动地躺在 UTXO 集合里——钱包也可能把它从收支史里漏掉。importprunedfunds 就是为这个盲区准备的补丁。

两个输入，各管一半真相

命令签名很诚实：importprunedfunds 接收一段原始交易的十六进制，加上一段 txoutproof 生成的默克尔证明十六进制。前者回答”这笔交易长什么样”，后者回答”它确实在某个区块里”。证明要由持有完整链的节点或可信区块浏览器提供：gettxoutproof 对指定交易输出那段编码证明，你的节点会独立验证它对应链上的默克尔根，验不过就不收录。官方描述还写明两个前提：交易的收款地址或脚本必须此前已在钱包里——它不会替你导地址，只补交易；以及目标用户需要自行导入后续消费这笔钱的相关交易，比如找零去处的子交易，否则钱包账本依旧不完整。

对余额的影响与回收入口

它的镜像命令 removeprunedfunds 按交易编号从钱包删交易，文档直说会影响钱包余额。两者合起来读，能得到这对工具的准确定位：它们不是导币或找回币的手段——资金在链上，从来不需要你”导入”才存在——而是钱包本地账本的增删。用错了方向，后果是账面自伤：把还在花的交易 remove 掉，余额立刻对不上；该 import 的找零不补，钱包会在后续发送时把不属于账本的输出当空气。因此操作窗口应当只有一轮：补录、用 getbalances 与区块浏览器对账、确认账面一致，然后停手。

操作顺序建议

第一步，向未修剪的节点请求 gettxoutproof 拿到证明，或从公开的区块浏览器导出同等格式的默克尔包含证明；第二步，从任意途径取到那笔收款的原始交易十六进制，交叉核对交易编号；第三步，importprunedfunds 导入，让节点验证证明成立；第四步，检查 listtransactions 与余额，再逐笔确认这笔钱之后的花费是否也要补录；第五步，做一次钱包备份。整个过程钱包不联网重扫、不依赖任何第三方持有你的私钥，是修剪节点少数几个纯本地找回账本的操作。

证明从哪来才可信

默克尔证明这条链上的信任锚点值得单独交代。gettxoutproof 的输出由一个持有完整链的节点生成，本质是该交易所在区块内默克尔树的压缩路径，任何持有完整链的节点都能独立验证路径通到链尖区块头的承诺。这意味着两条取证明的路径：向自己信任的另一台全节点要，或者从公开区块浏览器导出后再让你的节点验证——注意你的节点在导入时会验证明本身，伪造的证明进不了钱包，这条底线是软件保证的。风险点在于原始交易的来源：那串十六进制必须哈希回同一个交易编号，从不可信渠道拿到”看着对”的原始交易而证明又恰好是另一笔的，账就记歪了。所以顺序永远是先锁交易编号、再配证明、最后导入，一步不省。

本文仅讲解钱包机制，不构成任何投资建议；账本增删操作直接影响余额显示，执行前请先备份钱包并核对每个外部输入的哈希一致性。