一个 outpoint 交给清扫器：LND wallet bumpfee 的 RBF 与 CPFP 双路径

入口设计：命令的参数是 outpoint

比特币核心的 bumpfee 按交易 ID 提费，LND 的 lncli wallet bumpfee 则完全不同：参数是一个 outpoint——未确认交易里的某个具体输入。命令 Usage 原文是 Bumps the fee of an arbitrary input/transaction，描述写明它让用户直接和 LND 的 sweeper（清扫器）打交道：把一个从未确认交易里取出的 outpoint 交给清扫器去做潜在的费用提升。同一个入口后面藏着两条完全不同的路，走哪条取决于这个输入在清扫器里的登记状态。

为什么先看 listsweeps

源码建议在手动干预前先看清清扫交易的形态，原因在捆绑机制：清扫器倾向把同一时间窗内需要上链的多个输入捆进一笔交易——里面可能同时有强制关闭通道的输出、过期的预订单输入、自付回收的输出。RBF 对整笔交易的费用与形态有硬性约束，只想替其中一个输入加费，往往要重画整笔，替换余量随输入数量变化。先 listsweeps 看一次台账，能避免连续几次加费失败之后才发现根子在捆了不相干的邻居。

两个常见误读

一是把这条命令当成 Core bumpfee 的 LND 版：Core 按钱包交易提费，LND 按钱的归属调度，参数差异背后是整个清扫模型。二是把 deadline 理解成交易过期时间：源码语义里它是驱动费率函数的旋钮——越接近越激进，一级清扫的预算还会按配置比例烧掉，超期不等于交易作废，更不等于资金损失。对这两个旋钮建立正确预期，是手动提费与自动流程和平共处的起点。

两条路径：已登记走 RBF，未登记走 CPFP

源码 Description 的原话是：取决于这个 outpoint 是否已在清扫器中注册——已有的输入，例如锚点输出，会走 RBF；未注册的输入，例如一枚未确认的钱包 UTXO，会走 CPFP。解释一下这两条路的成因：RBF 是替换掉花费这个输入的那笔交易；CPFP 则是花掉那笔交易的低费输出、用子交易的高费带动父交易被打包——对清扫器来说，两种手法都是为了让同一个输入及其关联资金尽快上链，区别只在于替换谁。这就是为什么命令坚持收 outpoint 而不是 txid：提费的对象本质上是那笔钱，不是那张交易图。

费率函数：deadline 与 budget 在背后调表

LND 的 sweeper 不是简单一把加费。描述里说明了内部机制：清扫器需要理解一个输入的时间敏感度来做出经济的加费决策——内部用一个费率函数，由 deadline 与 budget 共同引导；当期限逼近，费率函数抬高费率并执行 RBF。强制关闭发生时，关闭交易的所有输出都会注册进清扫器，清扫器负责清扫交易的创建、广播与后续提费：每个新区块进来而清扫交易仍未确认，就再尝试一轮 RBF。想干预这套自动流程，才需要手动 BumpFee，指定自定义费率、预算、期限以及是否立即清扫。官方同时建议：先调 listsweeps 看清现有清扫交易的形态——根据其中输入的数量不同，RBF 的具体要求可以差得很远。

使用提醒

顺带一提，同一份说明还建议开启 sweeper.debug 日志级别观察调度决策——源码原话是这会产生非常啰嗦的输出，排障窗口之外别忘了关回去，日志盘满会拖垮节点本身。

顺带记录一个成本常识：RBF 提费的总费用是整笔清扫交易放大后的绝对值，捆的输入越多，替其中一个加费的边际成本越高。加费前先看清交易捆绑形态，再决定手动补刀还是交给自动流程。

批量清扫意味着多通道资金可能被捆进同一张交易：手动 bumpfee 干预前对不上台账，容易把费抬给了不相关的邻居。0.18 代起旧 bumpclosefee 已弃用，强制关闭提费另有 bumpforceclosefee 入口（其预算与期限参数行为本栏目另篇细讲），本文的 bumpfee 面向通用的任意输入。链上费率随拥堵波动，RBF 与 CPFP 都会追加真实链上成本且替换不保证成功；所有数值行为请以所运行版本的源码与实测为准，本文不构成投资建议。