闪电网络的 error 与 warning：一条决定通道生死，一条只拔网线

闪电节点日志里最常见的两个词是 error 和 warning。很多新手把它们当成同义词，实际上 BOLT 2 给这两个消息划了一条非常清晰的界线：出了错之后，这条通道还活不活。这条界线决定了运维动作是”等重连”还是”抢救资金”，值得单独讲清楚。

先看协议怎么定义。规范要求节点在检测到违规时二选一：发 warning 并关闭连接，或者发 error 并令通道失败（fail the channel）。也就是说，warning 的后果范围是连接——消息里可以携带出错的 channel_id，告诉对面”我在这条通道上发现了问题”，但节点只是掐断 TCP 会话，通道本身在双方的状态机里仍然存在，重连之后一切照旧。error 的后果范围是通道——发完之后该通道进入差错状态，双方应当把已知的最新承诺交易广播上链，用链上清算结束这段关系。同样是”对方说了不合规的话”，一个是拔网线冷静一下，一个是直接走法律程序，分量完全不同。

为什么要设计 warning 这个较温和的档位？核心考虑是可恢复错误的成本。闪电的很多检查项在断连重连后能自然修复：参数没对齐、消息顺序暂时混乱、某条可选 TLV 字段不认识。如果任何违规都升级为通道失败，那么每次网络抖动或版本差异都要花一笔链上手续费清算，整个网络的链上开销会失控。warning 给了实现一个”表达不满但不掀桌子”的手段，把纠错成本留在连接层。协议文本里大量条款就是”发送 warning 并断开连接，或者发送 error 并失败通道”这样的并列句式，把裁量权部分交给了实现者。

反过来，哪些错误必须走 error？典型的有两类。一类是状态不一致：重连后对方的承诺号、HTLC 号与自己记账对不上，特别是 channel_reestablish 阶段发现对方可能弄丢了状态——这类问题不解决就继续花钱，风险是资金损失，必须立即上链。另一类是不可协商的协议违规：签名验证失败、承诺交易构造错误、opening_transaction 与记账不符等。协议文本对此使用 MUST send an error 的强制句式，不给实现留连接级处理的余地。

排障时的解读方法可以按这个框架来。看到日志里只有 warning 加断连，先怀疑版本兼容、配置漂移或瞬时状态错位，重连观察即可；同一对端反复 warning 再查实现差异。看到 error，重点立刻从日志转向链上：确认己方是否已成功广播最新状态、惩罚窗口是否在计时、对端是否有旧状态广播的痕迹。这时”重连试试”是危险动作——通道失败之后继续通信没有意义，先把资金摘干净。

还有一点容易被忽略：warning 允许在连接层携带数据，且规范建议对不可打印字符的内容不要原样打印到日志。生产节点的日志采集链路要对这两个字段做截断和转义，否则对端随手塞来的调试内容可能污染你的日志管道——与比特币节点的 alertnotify 面临的是同一类工程问题：外部输入进日志，永远要消毒。

最后强调一个边界：error 失败通道是规范要求的”诚实收尾”，不是攻击手段。收到合法的 error 后，正确动作序列是取回自己最新的承诺交易、核对 HTLC 时间锁、必要时广播；整个流程里不该出现”把币转出去再说”的慌乱操作，因为你能花的只有你自己那一份，动作越急越容易上错车。

风险提示：本文所述为 BOLT 规范层面的机制，各实现（LND、Core Lightning、Eclair 等）的具体行为可能不同，操作前请以所用实现文档为准。强制关闭通道会产生链上费用，本文不构成投资建议。