闪电节点跑到一定年头，listchannels 里会逐渐多出一个看不见的”档案室”：那些已经关掉的通道并不会从数据库里蒸发，而是被压缩成一份份结关摘要，平时不占路由、不占内存，只在你要查账时现身。整理这间档案室的入口叫 closedchannels，它表面上只是一个列表命令，真正有信息量的是每条摘要里的 close_type 字段——它用六个枚举值记录了一条通道”是怎么死的”。
六种死法，对应六段不同的账务
接口定义把关闭类型列为六档。COOPERATIVE_CLOSE 是双方协商关闭：大家坐下来谈好各自余额，一条关闭交易体面落链，最常见也最省钱。LOCAL_FORCE_CLOSE 是我方单方面广播了本地最新状态把通道强关；REMOTE_FORCE_CLOSE 则是对面抢先落到链上，我方被动发现——同样是强关，主动权在谁手里，决定了你的资金要等多久、要不要走时间锁输出追回。BREACH_CLOSE 是所有人最不想看到的一档：对面把过期状态搬上了链，我方触发了惩罚交易，档案里留下的就是违约记录。另外两档与链上生命周期有关：FUNDING_CANCELED 表示开通道的资金交易被回滚，通道从未真正存在过；ABANDONED 则是人工执行放弃操作留下的标记。
摘要里跟着钱走的字段
每条摘要（ChannelCloseSummary）除了 close_type 还带一串结算线索：channel_point 是开通道那笔资金交易的位置，closing_tx_hash 是最终落链的关闭交易，close_height 记录资金交易被花掉的块高，capacity 是通道总容量。和余额最相关的两个字段是 settled_balance（关结时结算给本地的余额）与 time_locked_balance（关闭瞬间还处于时间锁里的金额）。做过强制关闭对账的人对后者深有体会：强关后我方那部分钱要经过 CSV 延迟才能花，查询当刻它们就挂在 time_locked_balance 上，等倒计时走完才并回可用余额。如果一笔”丢了的钱”在摘要里对上了 time_locked_balance，那多半不是事故，只是还没解冻。
按类型过滤的查账姿势
请求参数就是六个开关：cooperative、local_force、remote_force、breach、funding_canceled、abandoned，各自过滤对应类型。运维场景里最有价值的两个组合是：只勾 breach，用于快速自检”有没有被对手违约”——正常情况下这个列表应当永远是空的；勾上 local_force 与 remote_force，得到一份被动与主动强关的全史，用于统计哪条通道关系不稳、哪些对手节点常年失联。做迁移或清库前，把这份列表导出留档，也是通道数据的常规备份纪律之一，毕竟结关摘要本身也是通道历史里唯一的链下凭证。
档案室会占多大地方
值得说明的是，这份摘要常驻本地数据库，容量极小，与通道数量线性相关而与流量无关；它不会像转发历史那样需要分页和清理策略，也没有过期删除的自动机制——除非你手动删库，否则一条通道的死亡记录跟节点一样老。也正因如此，close_type 分布是一份诚实的健康报告：协商关占比越高，说明你对端关系越稳定；强关与取消频发，往往指向对方节点故障或资金交易在拥堵期被挤出链。
顺带一提，档案室本身没有公开隐私问题：结关摘要只存在你自己的数据库里，不会随图谱广播给任何人。查询它是纯本地动作，不产生链上费用，也不会触发与对端的通信。对任何一个跑过几个月的主网节点来说，这是最值得第一时间打开的抽屉之一——它不需要任何背景知识，只需要你在看到 breach 三个字时，知道该立刻去核对链上那笔交易。
还有一个常被问到的边界：结关摘要与链上数据是互证关系而非替代关系。摘要里的 closing_tx_hash 和 close_height 都是你可以在区块浏览器里逐条复核的链上事实，本地档案只是索引；反过来，链上那笔关闭交易解释不了 close_type 的语义——同样是关闭交易，协商关与违约关在链上的样子几乎一样，区分它们的证据只存在于节点自己的数据库里。这层”链上看不见、本地独有”的属性，正是这份档案的存档价值，也是备份纪律里它常被漏掉的原因。
风险提示：涉及通道关闭与惩罚交易的描述仅为机制说明，不构成收益承诺或操作建议；任何关闭与清库动作前请先备份静态通道数据。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。