lncli getrecoveryinfo：钱包恢复模式跑到哪了，进度条为什么不能当保证

一、恢复模式是干什么的

LND 从助记词或种子恢复到新设备时，链上历史比种子本身知道得多：旧地址在恢复前可能已经收过款。节点的做法是进入”恢复模式”（recovery mode）：按派生规则持续向新地址段推进，边派生边扫区块比对，直到把历史上用过的地址窗口全部覆盖。getrecoveryinfo 就是这条扫描流水线的进度窗：接口注释写明它返回三件事——当前是否处于恢复模式、恢复是否已完成、以及走到哪儿了。本文按 LND v0.19.0-beta 的接口定义核对这三个读数的含义与盲区。

二、三个字段怎么读

响应消息只有三行。recovery_mode 是布尔：钱包此刻是否仍在恢复扫描中。recovery_finished 也是布尔：恢复进度是否已经跑完。progress 是浮点数，注释注明取值范围从零到一，表示完成比例。三个字段要合起来读：正常节点常态下 recovery_mode 为 false；刚恢复完的节点一段时间内 recovery_mode 为 true 且 progress 在爬；扫描结束后 recovery_mode 归 false、recovery_finished 变 true。判断”恢复完成”应以后者为准，而不是凭 progress 爬到一——进度条与时钟不是同一回事。

三、为什么完成不等于安全

这是全篇最重要的一条边界。恢复扫描依赖的是地址窗口启发式：它扫描当前已派生路径附近的地址范围，把发现的收款补进账本。若历史上曾手动派生过超出扫描窗口的地址、用过不同派生路径的账户、或把同一套种子以别的 xpub 形态对外给过观察钱包，那部分旧地址的收款可能不会被这次恢复”发现”——进度条照样能走完。因此恢复完成后的正确动作不是直接收钱，而是做一次账本核对：把旧设备或旧备份里记录的余额、交易号与新区块账本对一遍，缺口再按地址扫描类工具补查。

另一个常见误判是把恢复模式与图谱同步混为一谈。LND 的 getinfo 里有 synced_to_chain 与 synced_to_graph 两个标志管链与地图，getrecoveryinfo 管的是钱包派生层的补账进度，三者各自推进，互不背书。

四、使用姿势

对普通用户，恢复钱包后的头几个小时里定期跑一次 getrecoveryinfo 看进度即可；期间节点照常可以收款，但余额显示可能暂时偏小，属正常现象，不要因此重复”重新恢复”打断扫描。对开发者，轮询该命令做引导页进度条是标准做法，但要给”长期停在同一 progress 值”设计提示：底层扫描受制于区块处理速度，进度卡顿通常意味着节点还在追链，先解决链同步再看恢复。

自动化脚本里注意两点：恢复结束以 recovery_finished 为门闩，不要在 progress 到一之后立刻执行后续初始化——两者可能相差一轮区块处理；恢复进度以节点自身推进为准，不需要也不应该用反复重启来”刷新”进度，若进度长时间不动，先查链同步再谈恢复。

五、与相邻命令的分工

getrecoveryinfo 只报告进度，不做控制：不能暂停、不能加速、也不能跳过。想看链同步用 getinfo 的同步标志；想看具体某笔旧收款有没有被补进账本，用 listtransactions 与 scantxoutset 类工具在比特币节点侧交叉核对。恢复完想验证某个旧地址仍归本钱包管，直接对派生路径做一次 deriveaddresses 比对即可。

六、恢复期间的收款处理

恢复扫描进行中的节点对新收款完全正常：新地址照常派生、二维码照常给出，钱进来只是暂时还没进对账单的显示范围。真正要避开的是恢复中途改设定——换密码、调整地址窗口、或者把同一套种子再导进第二台设备同时扫描，都会让两套账本各扫各的，日后对账平添变数。稳妥节奏是：恢复期内只做只读观察，任何需要改动钱包结构的动作都等 recovery_finished 落定、账本核对完成之后再做。对运营方还有一点值得记：恢复完成的信号适合直接接在部署脚本末尾，轮询到 recovery_finished 为真再放开通道开通、余额展示之类的后续初始化，把进度条与对账两条都过完，恢复闭环才算走完。

风险提示：恢复完成但余额不符时，请勿把助记词交给任何网页或”客服”核对，必要时在隔离环境自查。本文不构成投资建议。