成功付款里那些失败的尝试还在不在：keep-failed-payment-attempts 的存储取舍

闪电节点的付款很少一次成功：第一条路径失败，换一条再试，最后整笔付款成功。问题在于历史账本里留什么——只留”这笔付款成功了”，还是连”之前失败了哪几次、为什么失败”一起留。LND 用一个配置项决定这件事：keep-failed-payment-attempts。很多排障现场查不到失败原因，根因其实在这个开关的默认值上。本文按 LND v0.19.0-beta 源码核对。

默认值与语义

源码里的注册文本是：Keeps persistent record of all failed payment attempts for successfully settled payments，默认值 defaultKeepFailedPaymentAttempts = false。注意这句话的限定结构：它管的是”最终成功的付款”名下那些失败尝试的持久化。对最终没成功的付款，失败记录本来就在账本里；争议点只在成功付款——成功那一刻，之前的失败尝试是归档还是丢弃。默认 false 意味着丢弃：查询一笔成功付款，你看到的是成功的结果与最终路径，中途的失败尝试不留痕。

打开之后账本变成什么样

开启该选项后，成功付款的每条失败尝试都被持久保存，listpayments/trackpayment 一类接口能把尝试序列翻出来：哪条路由在哪个节点返回了哪个失败码、每次尝试的金额与时间。这对两类工作价值极高：一是路由质量分析，统计自家节点反复在哪些上游失败，指导通道开在哪；二是对账与纠纷回溯，用户报”付款转了很久才成功”，你能拿尝试记录解释延迟来自几次路由失败重试。代价同样直白：数据库里支付尝试表的增长率上升，一台路由繁忙的节点可能从”每笔付款一行”变成”每笔付款多行”，磁盘占用与备份体积随之上来。

默认关掉的合理性

LND 把它做成默认关闭，背后的权衡是：绝大多数用户的账本诉求是”钱到了没有、走哪条路”，成功付款的内部重试细节属于诊断数据，不是账本数据；而路由节点的诉求是反过来的。这个开关的存在让同一份代码同时服务两种画像——普通节点保持账本干净，路由运营者拿到完整尝试史。

操作层面的注意点

第一，它是启动配置项：只对开启之后发生的付款生效，已经丢掉的失败尝试不会因为你打开了开关而回来。第二，评估容量再开：先看清自己的月度付款量与通道规模，开启后观察数据库增速，再决定长期保留还是阶段性打开。第三，与查询接口的分页参数配合使用：尝试记录增多后，按索引翻页要意识到总行数变了。第四，改动配置后重启节点生效，验证方法是发起一笔必然多跳的付款，再确认接口里能否看到失败尝试——看不到就检查配置是否真正加载。

一个决策流程图式的收尾

先问自己三个问题：我会分析路由失败原因吗？我的数据库与备份空间紧张吗？我现在的查询里有没有依赖”成功付款只有一行”的隐含假设？第一问答”是”且第二问答”够”，就开；第一问答”否”，保持默认；第三问答”否”但下游有导出脚本，先验证脚本能容忍尝试行数的变化再开。开启后建议以周为单位观察数据库大小曲线，确认增速在可接受范围，并把”尝试记录存在”写进你的排障手册：下次凌晨三点查一笔”转了三次才成功”的付款时，你会感谢这个当时看起来不起眼的配置项。

风险提示：支付元数据的保留策略涉及隐私与合规的自我评估，尝试记录会暴露付款的时间与路径特征；本文为机制说明，不构成投资建议。