通道异常关闭的交易 broadcast 出去之后卡在内存池里无人理，是闪电运维里最烧钱的一幕：惩罚窗口在倒计时，链上确认却遥遥无期。LND 给锚定通道准备了一个专门的加费入口——walletkit 里的 BumpForceCloseFee，命令行 lncli wallet bumpforceclosefee。它不是普通的 bumpfee，背后连着一套会越烧越猛的清扫器预算逻辑。本文以 LND v0.19.0-beta 源码为准。
先确认你有资格用这个命令
接口文档里那句限定非常重要：这个端点只对带 option_anchors 的通道生效。锚定通道在链上关闭交易里留了一个专门用于加费的锚定输出，BumpForceCloseFee 花的就是这笔输出，走 CPFP 思路——用一个高费率的子交易抬升整条依赖链的有效费率。旧式非锚定通道没有这块专用燃料，对它加费需要别的姿势（比如改动整笔关闭交易的费率逻辑），这条命令帮不上忙。查通道特性可以从 ListChannels 或图谱信息里核对。
请求参数里藏着一台燃烧炉
命令接受三个关键输入。chan_point 指明是哪条通道的关闭交易。deadline_delta 是可选的区块数：它告诉清扫器，锚定输出要在这个期限内被花掉——而且注释写得很直白，期限一到，全部预算将作为手续费花出去。这就是这套机制的双刃剑：它保证交易一定会被挤进块，代价是越拖越贵，最后一分不剩全给矿工。starting_feerate 也是可选的，单位 sat/vB，给清扫器的费率函数一个起跑线；不填的话就用 target_conf 估算出来的费率起步。
把这三个字段连起来读，能明白它的设计意图：宁可花光预算，也要在惩罚窗口内完成确认。这是保命钱逻辑，不是省钱逻辑。
使用时机与排错
典型触发场景有两个。一是对手方单方广播了关闭交易而费率偏低，自己这边必须在窗口内确认，直接对该 outpoint 加费。二是本地发起的强制关闭赶上网络拥堵，首包费率估算失准，用 starting_feerate 指定一个更激进的起点重启清扫节奏。
排错时注意：加费交易本质是子交易，它的有效费率取决于父交易（关闭交易）本身。如果父交易费率低到被节点的中继下限拒收，子交易再高也进不了内存池，这时问题出在父交易的费太离谱，单纯加大子费没有意义。另外，如果同一条通道有多个清扫目标共享预算，加费行为会在清扫器内部排队，观察钱包的清扫台账比单看这条命令的返回更有全局视野。
纪律三条
第一，能用协商关闭就不给强制关闭留登场的机会；第二，用这个命令前先核对通道确实是锚定型，避免对着旧通道空转；第三，deadline_delta 不是越短越安全——它决定的是燃烧速度，设定时要对照通道参数里的惩罚延迟，保证确认期限在惩罚窗口之内。
与钱包清扫台账的配合
加费动作由清扫器统一调度，多个清扫目标会在内部排队。单看 bumpforceclosefee 的返回只知道这笔是否被接受，看不到全局节奏；配合钱包侧的清扫台账，才能判断这笔在队列里的位置与预计生效时间。拥堵时段连续手动触发不会更快，只会叠加成本，耐心让清扫器跑完一轮通常更省。
两条不需要动手的情形
有些看起来该加费的场面其实不该动：如果关闭交易的费率尚可、只是排在了队列后排，耐心等块通常更省；如果节点内存池配置过于保守，把子交易挡在门外，正确的动作是修本机的中继参数或对端连接质量，而不是抬高加费预算去挤一扇本可以打开的门。动手前先回答一个问题：这笔交易现在是被拒绝，还是只是没被优先？答案决定你要花钱还是修配置。
风险提示：强制关闭与加费操作涉及真实资金与不可逆链上交易，请先在测试网完整演练；本文不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。