AUG56 bitcoin body 256: lncli neutrino 命令族

把 lnd 的链后端切成 neutrino，节点不再需要陪跑一个全节点，但代价是多了一个需要自己照顾的轻客户端。lncli neutrino 命令族就是照顾它的仪表盘：六条子命令管状态、连人、封禁与取数。很多人只记住了“neutrino 省事”，没记住这些读数从哪看。

先说两个前提

第一，这组命令不是装好 lnd 就有。源码布局上，neutrino 子命令组由 neutrinorpc 构建标签控制：发行版二进制通常带这个标签，但从源码自行编译时忘了加，lncli neutrino 整个组就不存在，报未知命令。第二，后端选择不能反悔。官方样例配置的说明写得很直接：在完整后端（btcd、bitcoind）与轻后端（neutrino）之间切换是不支持的，bitcoin.node 从哪边切到哪边都不算热改，链上状态语义完全不同。选错重来的正确姿势是重新初始化数据目录，不是改一行配置重启。

六条子命令各管一段

status 返回运行中的 neutrino 实例状态，附带最佳区块的高度与哈希以及已连接对端列表，是巡检的第一屏：轻后端的同步进度、断连迹象都在这里。addpeer 与 disconnectpeer 分别按地址增加和断开对端，对应配置文件里的 neutrino.addpeer 的运行时版本。isbanned 按地址查询封禁状态——注意，neutrino 有自己的一套对端管理，和 lnd 主进程的对端列表是两本账。剩下两条是取数工具：getblockheader 按哈希取区块头，getcfilter 按哈希取紧凑区块过滤器，这两条命令把“轻客户端到底收到了什么”变成可以逐块抽查的对象。

配置文件里那两个“当前未使用”

[neutrino] 段里有两个参数值得点名：neutrino.banduration 和 neutrino.banthreshold，样例配置在各自注释里都标注了“此值当前未使用”。也就是说改了封禁时长和封禁分数线，行为不会有任何变化，指望调低 banthreshold 来放松对端纪律的人会白忙一场。真正建议动的是 neutrino.connect：样例注释写明推荐设置常驻对端，因为支持 neutrino 协议的网络节点数量本来就少；neutrino.maxpeers 默认值为 8，控制入站出站对端总数上限。assertfilterheader 则提供以“高度:哈希”格式断言过滤器链头状态的开关，断言失败时从创世块重新同步过滤器头——排过滤器链错乱时，这是比删库更温和的自愈入口。

一条实用排障顺序

节点迟迟不确认开通道请求时，先 neutrino status 看高度是否追上网尖；不追则看 peers 列表是否为空，空就 addpeer 或用 neutrino.addpeer 配常驻对端；高度追平但通道仍不动，问题多半在 lnd 与后端的对账层而不是同步层。轻后端省下的每一份磁盘，都是以多一层可以自己查的状态为代价的，这六条命令就是那层状态的门面。

与主进程对端体系的三本账

这台节点其实同时维护三套网络关系：lnd 自己的闪电对端、后端连接、以及 neutrino 实例的轻客户端对端。lncli listpeers 看第一本，neutrino status 的对端列表看第三本，isbanned 查的封禁也只在第三本账里生效——主进程不会因为某个地址在 neutrino 侧被禁就拒绝它作为闪电对端。排障时拿错账本是常见的自我误导：明明 neutrino status 显示零对端，却去闪电层查路由问题。另外 getblockheader 与 getcfilter 的取数路径完全走轻客户端自己拼出的请求，返回异常时优先怀疑对端数据质量而不是本地校验逻辑，这两条命令是少数能把同一个高度向多个常驻对端各取一遍再互相印证的入口，交叉核对的成本只有几条命令。

最后提醒构建标签的排查姿势：从源码编译时把 lncli help 的输出与发行版对照，命令组的缺席比报错更安静——没有 neutrino 组不代表后端没配好，可能只是编译时没带那个标签，重装发行版二进制再回头排配置，能省半天。

风险提示：轻后端依赖外部对端提供区块与过滤器数据，对端质量影响节点确认行为；本文为机制说明，不构成投资建议。