lncli getrecoveryinfo 的三个字段：钱包恢复进度的正确读法

给闪电节点做链上初始化时，钱包恢复模式（recovery mode）是一个常被误读的状态词：它既不是”同步中”的同义词，也不保证恢复完成后一切就绪。lncli getrecoveryinfo 就是专门回答这个问题的命令——它把钱包是否处于恢复模式、恢复是否完成、以及一个 0 到 1 之间的进度值三件事拆开汇报。

一、命令返回的三个字段 在 LND v0.19.0-beta 的接口定义里，GetRecoveryInfoResponse 只有三个字段：recovery_mode 布尔值，表示钱包当前是否处于恢复模式；recovery_finished 布尔值，表示恢复过程是否已经跑完；progress 一个 0 到 1 的双精度数，表示恢复进度。注意第三个字段没有配套的高度信息，它是一个归一化比例，分母是钱包从 Birth Time（种子首次上链的高度）到当前链尖之间的区块跨度。这意味着当网络端持续出块时，即使节点什么都不做，这个数字也可能长时间原地踏步——目标本身在往前挪。

二、钱包恢复与图同步是两条线 最容易混淆的地方在于：getrecoveryinfo 管的是钱包账本恢复，而 lncli getinfo 里的 synced_to_chain 和 synced_to_graph 管的是链与通道图的同步节奏。一个节点完全可能钱包恢复早已完成、通道图还在补课，也可能图同步正常、钱包恢复仍在扫描历史区块。把三条进度串成一条”总进度”来监控，是运营监控里非常典型的口径错误。写监控脚本时，请把它们当三个独立信号各自设告警。

三、恢复模式什么时候出现 钱包恢复通常发生在你用种子（如 aezeed 助记词）重建钱包、或者手动开启了 lncli recover 之后。此时节点需要把 Birth Time 以来的全部区块扫一遍，找出与种子相关的每一笔链上事件，才能重建通道余额历史。恢复期间节点会拒绝部分需要完整账本的操作；对普通用户来说，最直观的感受是开通道、收款发票等功能在恢复完成前可能报错或行为保守。恢复一旦启动，除非你显式中止，它会自己跑到链尖。

四、进度条为什么不能当保证 把 progress 直接翻译成”还剩几分钟”是不严谨的。原因有三：其一，扫描速度取决于区块数据所在磁盘的随机读性能与过滤命中密度，不同历史区间速度差异很大；其二，恢复期间链仍在出块，分母持续变大；其三，进度按区块数计，与钱包实际恢复出的余额多少没有线性关系。工程上更可靠的完成信号是 recovery_finished 翻真，再配合 getinfo 里的同步标志做交叉确认，而不是盯着进度值做线性外推。

五、运维与恢复场景的正确姿势 用种子重建钱包后，第一件该做的事是确认 Birth Time：恢复跨度越大（老钱包、久未动用的托管钱包），恢复耗时越长。第二件事是明确期间不要重复导入同一份种子或多路并发恢复——钱包文件按独占方式打开，并发操作只会互相报错。第三件事是恢复完成后先小额验证：让一笔测试收款走通、在钱包余额与链上对账一致后，再恢复正常业务。对闪电钱包而言，链上余额与通道余额还各自独立，walletbalance 与 channelbalance 需要分开核对。

六、边界与例外 如果 LND 后端是外部钱包（bitcoind 或 Neutrino 之外的独立记账后端），恢复语义以对应实现为准；如果钱包从未使用种子重建，getrecoveryinfo 应返回 recovery_mode 为假、进度字段不再随时间变化。若节点在恢复期间崩溃重启，恢复会从断点继续而不是清零重来，但重启期间图同步和链同步会各自补自己的账。对多钱包部署，恢复状态是按钱包逐个记录的，不要把某个钱包的进度误当成整个节点的进度。

风险提示：本文机制描述以 LND v0.19.0-beta 源码与官方接口定义核对为准，字段与语义可能随版本变化，请以实际所用版本为准。种子与恢复操作直接关系资金安全，恢复期间的任何”加速脚本""第三方恢复服务”都存在泄露资金的风险，本文不构成任何投资建议。