lncli deletepayments 清理付款历史：在途付款为什么删不掉

一、listpayments 只进不删，删除是另一组命令

listpayments 把出站付款的历史摊开，但它自己没有任何清理能力：付款记录只会随时间越积越多。真正把删除能力挂进主接口的，是 DeletePayment（按单笔）与 DeleteAllPayments（批量）——lncli 侧对应 deletepayments 与带 --all 的同名命令。本文按 LND v0.19.0-beta 的接口定义核对这两条命令能删什么、不能删什么、删错了会失去什么。

二、两条命令的参数形状

按哈希删除的请求消息只带两项：payment_hash 指定目标付款；failed_htlcs_only 是一个开关，打开时只清理这笔付款里失败的 HTLC 尝试记录，付款本体保留。批量命令的字段变成三个布尔：failed_payments_only 只删失败的付款；failed_htlcs_only 只删各笔付款里失败的尝试；all_payments 则删掉全部出站付款，接口注释特意加了一句”使用该选项需要谨慎考虑，因为它是破坏性操作”。

两条命令共享同一条安全线，而且写在了接口注释的第一句：处于在途（In-Flight）状态的付款一律不删，因为那会破坏路由器的状态机——洋葱分片可能还在路上，删了记录等于自毁对账依据。命令层面它们分别返回一个 status 字符串表示操作结果，不提供任何可恢复承诺。

三、删掉之后，哪些信息永久消失

付款记录在 LND 里不止是”历史账单”。第一，Mission Control 的通道通过率数据来自历史尝试，删记录不直接删统计，但排障时”这笔为什么走不通”的可查证据没了。第二，删除是本地数据库操作，链上什么都不会变：已确认的付款依然可以在链上找到，发票（invoice）侧的结算记录也不受影响——出站账本删了，入站台账还在。第三，同一 payment_hash 若在删除后重付，系统按新付款重新记账，历史上”付过两次”的事实只剩发票侧和对端能证明。

因此删除的真实边界是：它清的是本机出站视角的账，不是资产动作本身。任何靠付款哈希做事后证明的场景——对账、纠纷、备份比对——都要先把这条记住。

四、使用姿势与自查

批量命令的三个布尔有严格的参数校验：全为 false 会被直接拒绝，返回”至少要把 all_payments、failed_payments_only、failed_htlcs_only 中的一个设为 true”；all_payments 与另外两项同时为 true 也是矛盾组合，同样报错——因为”全部”已经包含失败记录，再叠加过滤没有意义。执行结果写进返回的 status 字符串，带上删除条数。脚本里把意图写明确：只清失败记录就加 failed_payments_only；要清空就显式给 all_payments，注释里那句破坏性警告就是为这条路径准备的。

五、与相邻清理能力的分工

发票侧的删除走 delinvoice / canceledomain 等收单命令，通道侧的路由历史走 fwdinghistory 与删除参数，各有各的接口和语义。deletepayments 只管出站付款这一本账，别指望它顺带清理发票或转发记录。同理，deletepayment 单笔版的 failed_htlcs_only 只适用于单笔付款；要全局清失败尝试，用批量版加对应开关。

六、发票侧与转发侧的对应清理

出站付款只是闪电节点三本账之一。发票台账由 listinvoices 与订阅发票流管理，删除或作废走 cancel 类接口，清掉发票会把尚未结清的收款请求一并作废，影响面比删出站记录更大，操作前先确认没有分片付款还在路上。路由节点的转发记录走 fwdinghistory 查询，是否清理取决于合规要求——转发记录是路由收入对账的原始凭证，多数运营者选择长期保留。三本账删任何一本都不影响链上事实，但都会削弱本机举证能力，因此『节点磁盘快满了删点记录』这种动机下，优先删的永远是失败尝试这类低信息量条目，成功付款记录尽量以导出快照的方式归档而不是就地销毁。

风险提示：删除付款记录不可恢复，可能影响你的对账与纠纷举证能力。本文只做命令与边界说明，不构成投资建议。