闪电通道的双重上限：余额之外，HTLC 槽位如何锁住你的付款

通道不只被容量卡住

闪电网络通道的直观约束是余额：通道总容量一亿聪、你一侧持有三千万聪，就只能付出最多三千万聪（收款方向则看对方一侧的持仓）。但实际运维里更常见的怪现象是：明明还有余额，新付款却一直被拒。第二重约束——HTLC 槽位与承诺交易体积——才是元凶。

槽位的物理来源

闪电通道里的每笔在途付款都是一个 HTLC：用哈希锁与时间锁在双方承诺交易上占一个输出。承诺交易必须塞进可relay的重量限制，而每多一个 HTLC 输出就多一份脚本与签名体积。协议因此对单条通道的在途 HTLC 数量设了上限，主流实现默认的上限是每方向四百八十三笔；同一通道同时可以挂接收方向的与发送方向的各一批，但每一批都受各自承诺交易的重量预算约束。除了数量，还有两个闸门：每笔 HTLC 不得低于 dust 与 htlc_minimum_msat 定义的尘埃线；全部在途 HTLC 的合计金额不得超过节点自设的 max-HTLC-value-in-flight。

什么时候会被槽位卡死

三类场景最常见。第一，路由节点长期挂大量小额在途：HTLC 未超时又未结算，槽位被占满，后续任何付款——包括你自己的——都进不来。第二，对手端把 HTLC 挂到接近超时：超时前的每一分钟，你的通道都处于“半冻结”，既不能安全关闭也不能自由使用被占的额度。第三，链上费率暴涨：新承诺交易要支付的链上费用上升，重量预算里留给 HTLC 的部分被挤压，通道可能出现“有钱有槽也开不了新 HTLC”的角落情况。lncli pendingchannels 与 Eclair 的对应接口能直接看到被冻结的 HTLC 列表，这是排查第一步。

槽位的另一面：被攻击的面

槽位上限也是拒绝服务的攻击面。闪电开发者社区（Bitcoin Optech 的专题页有完整线索）记录了两种经典打法：流动性挤压让攻击者把资金沿二十跳路径发给自己并故意不结算，用一份本金锁住沿途多份他人资金；HTLC 挤压则用四百八十三笔低于尘埃门槛的小额占满每个槽位，两条通道就能瘫痪上万条诚实付款槽，而失败付款不产生路由费，攻击近乎免费。协议至今没有部署全网强制的反挤压方案，现实防御来自节点侧：按对等端限制并发 HTLC 数（例如给单一对端设十几笔的天花板）、对异常超时参数直接拒收（Eclair 曾把接收端 CLTV 超时超过未来两千零一十六块的 HTLC 直接判失败）、以及本地信誉或前置费实验。理解槽位，既是为了用好通道，也是看懂路由节点为什么对你的付款说“暂时不行”。

用户视角的三句话

收款方遇到大额通道付款失败，先怀疑对方出站流动性与槽位，而不是自己节点坏了；开通道时把双方 dust 线、cltv 参数与 HTLC 上限写进检查清单；运行路由节点则给每通道设 HTLC 并发上限、给对端设超时纪律，是成本最低的自保。还有一条容易被忽略的常识：槽位与余额是乘法关系而非加法关系——即使通道里还有大量空闲资金，只要四百八十三个槽被占满，新的任何付款请求依然会被直接拒绝，因此只盯余额面板的运维视角天然会漏诊这类故障。

常见误区

“余额够=能付”——忽略槽位与重量预算的经典结论，也是答疑区反复的根源。“通道里在途 HTLC 是隐私泄漏”——HTLC 的哈希锁与洋葱路由设计正是为了相互不可区分，可见的只是数量与大小分布。“槽位越高越抗攻击”——恰恰相反，放任单对端的 HTLC 并发才是攻击入口。

风险提示

本文只讲机制与防御，不构成运营路由节点的收益预期。各实现参数默认值随版本变化，以对应软件文档为准。