通道容量大不等于放得下你的付款：htlc_maximum_msat 的窗口语义

闪电网络里”通道容量大”不等于”你的付款能走这里”。一条公告通道在路由图上的可用性由 channel_update 消息描述，其中 htlc_minimum_msat 与 htlc_maximum_msat 一上一下两个字段框出单笔 HTLC 的尺寸窗口，上沿字段专门用来表达转发方”我不愿意单放过这么多”的意愿。本文按 BOLT #7 的字段规则与路由建议拆解这个上沿怎么读。

字段语义：单边意愿，不是物理容量

htlc_maximum_msat 是”本节点愿意经这条通道这个方向转发的单笔 HTLC 上限”，以毫秒聪计。它是 channel_update 固定字段的一部分（在 htlc_minimum、费用两字段之后），随每次重签公告更新。规范对发送侧的约束是：必须不超过通道容量、不超过开通道时对方给的在途总额上限、且不低于下沿。注意主体：这是转发节点的单边声明——容量很大的通道完全可以把上沿设得很小，用一行参数把大单挡在外面，而物理余额照常可以走小额。

接收侧的判定表

BOLT #7 对读进这条公告的节点给了具体建议。上沿小于下沿：这条通道在路由计算中应当直接忽略，因为不存在任何合法尺寸能穿过。上沿大于通道容量：公告自相矛盾，节点可以把这个节点 ID 拉黑，并在路由中忽略该通道——这是规范里少见的”允许拉黑同行”条款，因为这种矛盾通常指向实现错误而非恶意。其余情形：选路时应当把上沿纳入考量。付款金额落在窗口外的后果分两种：低于下沿通常撞尘埃防护类错误码；高于上沿则被中途节点拒绝后换路重算，对付款方表现为一次静默的失败重试。

时效：两周与剪枝

channel_update 带时间戳，规范建议：若某一方向的更新时间戳超过两周（原文给出的秒数是 1209600），可以剪掉这条通道；由于一个方向的更新不更新不影响另一方向可用，判剪枝用的是两边时间戳里更旧的那个。剪枝是每台节点的自身策略——转发对端不能强制执法——所以改过上沿却没重签公告的通道，会在别人的路由图里慢慢变透明，而不是立刻消失。运营侧的推论很直白：改参数之后要让两个方向都重签，只改一侧等于留了一个别人能绕过限制的入口。改参数还牵出另一条建议：新公告从签发到全网收敛有传播时延，付款方可能还拿着旧参数选路，因此节点被建议把旧参数的受理窗口至少保持十分钟，避免新旧交替期把在途付款弹回来。字段演进还有个冷知识：message_flags 里原先有个 must_be_one 位，用来标记公告是否携带 htlc_maximum_msat；如今该字段成为必带项，这一位变成常量、接收方直接忽略——上沿从”可选声明”到”强制义务”的变化史就写在这半个字节里。

运营侧的取舍

把上沿设低是精细的流量整形：拒绝”一笔吃掉通道流动性”的大单，把大额流量推向拆单或专用大通道；设成与容量等高则最大化吞吐、同时接受 HTLC 挤占与在途风险。上沿与费用字段组合起来，本质是这个节点对该方向流量开出的受理条件公告——路由软件会把它和其他候选通道的窗口、费率、时间戳放在一起排序。还有一条消息结构层面的运营常识：channel_update 里的 channel_flags 带方向位与 disable 位，message_flags 里有必须置 1 的标志位和一个”不要转发”位（带它的公告只在本地生效、不再扩散，属于隐私工具），公告只对声明的那个方向有效，两个方向的窗口和费率可以完全不同。所有阈值以 lightning/bolts 规范当前文本为准。本文只解释协议机制，不构成投资建议。