一、余额不对，多半是钱包没听课
全节点日复一日验证区块，钱包只是它的一位旁听生：交易进来时，节点把涉及本钱包的输出记账入账。新导入的钱包、刚恢复的种子、或者创建时指定了较早出生时间的钱包，相当于缺席了前面所有课，账本自然是空的。rescanblockchain 的作用是让这位旁听生把讲义重新读一遍——把历史区块逐块与钱包密钥匹配，找回错过的每一笔。
二、参数与进度
命令接受两个可选参数：起始高度与结束高度，缺省从创世块扫到调用时刻的链顶。返回结果给出实际起止高度。扫到一半时想看进展，文档的答案很干脆：用 getwalletinfo 查询扫描进度。需要设结束高度吗？通常不要——除非你只想确认某个窗口内的进出账。对时间线明确的老钱包，用合理的起始高度能省掉几小时的空扫。
三、描述符钱包与区块过滤器加速
文档里藏着一句对速度影响最大的话：描述符钱包配合启动参数 blockfilterindex 开启区块过滤器索引时，重扫显著更快。原理在于每块都附带一份轻量过滤器，只回答这个块里有没有和本钱包相关的字节，绝大多数块看一眼过滤器就跳过，省掉逐块全量匹配的开销。所以同样的恢复任务，配置不同的钱包文件与节点参数，耗时可以差出一个数量级——动手重扫前先花一分钟检查这两项。
四、reorg 会让 stop_height 变成空值
返回字段里 stop_height 在少数情况下为 null，文档给出的解释罕见但真实：存在重组时，部分区块已经在后台扫过，本次调用没有再推进任何块。运维脚本不能假设结果永远是两个数字，null 分支要显式处理，否则监控会在重组日莫名报警。
五、耗时预期与更省钱的替代路径
全历史重扫在一台消费级机器上以小时计是常态，规划预期比寻找奇迹更重要。三条省时间的正路：导入密钥时就把创建时间设准，让重扫从正确的年代开始；启用过滤器索引与描述符钱包；恢复完成后先用起始高度做一段窗口验证，再放全量任务在低峰时段跑。至于第三方扫描接口，它把你的地址与出生年份暴露给了一个陌生服务商，隐私代价自己权衡。
本文内容为钱包运维科普，不构成投资建议；恢复流程请先用小额测试钱包完整演练。
六、恢复演练把不确定变成确定
重扫最怕的不是慢，是慢完之后没人敢确认结果对不对。省心的办法是平时做一场演练：用一个测试钱包生成一串助记词，往测试网或小额主网地址收几笔分散在不同高度的转账，记下每笔的高度，然后把钱包删掉重建，从助记词恢复并重扫，对照清单逐笔打勾。这场演练会顺带回答一堆平时说不清的问题：你的节点在什么配置下重扫最快、扫描进度的数字怎么换算成预计剩余时间、恢复后的余额与当初是否一致。演练做过一遍，真到恢复日，重扫就从一场焦虑的等待变成一项有基线的例行核对——这也是自托管与托管最本质的区别：信任不靠别人担保，靠你自己验证过。
七、重扫期间与重扫之后
两个时间点各有注意事项。扫描期间，钱包的余额与交易列表是不完整的，监控脚本若把重扫中的零余额当成丢币告警，会制造不必要的恐慌，正确做法是读扫描进度、等它归位再报警。扫描结束后，若清单上仍有转账找不到，先核对两件事：这笔钱是否真的到过本钱包的密钥——用外部区块浏览器独立确认接收地址的归属，别让钱包自己给自己作证；以及节点本身的链是否同步到位，重扫追不上未同步完的节点也是空忙一场。两问都过了还缺记录，才轮到怀疑导入参数与派生路径。顺序清楚地走完这三步，绝大多数恢复纠纷都能在自家机器上定案。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。