闪电网络大额付款怎么拆分？基础多部分支付 MPP 机制详解

先说结论：分片是搬运，不是省钱

闪电网络里发起一笔超过单条通道可用额度的付款时，钱包可以把金额拆成若干笔 HTLC，经不同路径同时送往同一收款节点：每笔都带同一个 payment_hash，并用 total_msat 字段声明这笔支付的总额。收款端把这些同哈希的 HTLC 归为一个集合，全部到齐才一次性放行，凑不齐就整组退回。这套机制叫基础多部分支付（Basic MPP），规则在 BOLT4，能力位 basic_mpp 定义在 BOLT9。

协议规则拆解

拆分的合法性来自三条约定。第一，同一 HTLC 集合内 total_msat 必须一致，收款节点发现不一致可以整组失败。第二，总额有上界：发票写明金额时，total_msat 至少要等于该金额，且不得超过其两倍——这条限制是为了防止收款方挂起发票坐等多出来的碎片，造成通道资源被占用。第三，每个分片都必须携带 payment_secret，收款端靠它把碎片归入同一笔支付，而不是凭金额猜测；在启用隐藏路径的场景里，还有一个总数字段承担同样的声明作用，因为那种情况下 payment_secret 语义并不适用。payment_metadata 会随每个分片携带，便于尽早发现配错。 凑不齐怎么办？规范给出的结局是超时整组失败：收款节点应至少等初始 HTLC 到达后约 60 秒，仍未满额就以 mpp_timeout 失败码退掉全部碎片。拆分支付因此天然带有一段半收款状态窗口——它是协议内部状态，不是入账了一半。

能力协商与发票

能不能拆分，取决于双方是否声明了 basic_mpp，该能力位还会出现在发票里，并依赖 payment_secret 这一前置能力。发起方在写入分片时应当同时发出、尽量走不同路径，失败的片段应当重试或重新划分；收款方一旦放行集合中的任何一笔，就必须放行整个集合。这些约定共同保证了要么全成、要么全退的原子性。

和普通用户的关系

普通用户一般不主动选择分片：钱包与节点之间的能力协商决定能不能拆，双方都支持时拆分是软件层行为。它的实际意义有二：一是流动性受限时，分片能拼出单笔通道给不出的额度；二是解释某些失败——对方不支持 basic_mpp 或发票缺少相应字段时，大额单路径支付只能碰运气。

边界与风险

分片不改变闪电的清算经济学：每个分片仍是通道内的 HTLC 更新，不额外产生链上费用；但超时窗口内通道额度会被占住。对账时要理解所有或全无语义：不存在收到一半碎片的中间态，链上与通道状态都不应出现部分入账。规范细节可能随 BOLT 修订变化，接入开发以 lightning/bolts 仓库当前文本为准。本文只做机制科普，不构成投资、选路或交易建议。

与原子多路径和盲路的区别

要注意 basic MPP 只是最基础的一种拆分：同哈希、多笔 HTLC、原子结算。更复杂的原子多路径方案会在哈希派生上做文章，让各分片用不同派生哈希但仍可原子结算，以削弱仅凭 payment_hash 关联分片的能力；盲路径方案则通过路径隐藏改变归组所需的字段。三者解决的问题不同：basic MPP 解决通道额度与路由可用性问题，后两者更多面向隐私与拓扑隐藏。普通用户看到的仍是一笔成功或失败的支付，区别只出现在钱包日志与故障定位里。理解这一层，读闪电网络的路由类文章时才不会把不同代际的机制混成同一个开关。

失败归因的实操顺序

遇到支付失败，钱包给出的抽象错误码背后往往是三类原因：分片能力未协商成功、某一分片在中途通道耗尽流动性而失败触发整组回退、或收款端在超时窗口内没有集齐。排查时先看是否为大额或零钱发票场景，再看钱包日志里是否记录了分片数量与 total_msat，最后才是通道层面的路由记录。理解分片机制的价值就在这里：它把一个看似玄学的大额失败拆成可核对的状态，而不是让用户只能反复重试。需要强调的是，所有重试都应保持同一 payment_secret 与一致的 total_msat，否则收款端会把碎片归到不同集合，既凑不齐也退不干净。