给自己记门牌号不通知对面：XAddLocalChanAliases 与 XDeleteLocalChanAliases 的本地账

先分清两种别名

关于闪电通道的编号，本栏目已讲过短通道 ID 的构成，也讲过 option_scid_alias 协商出来的假门牌——那类别名会通过消息让付款方在路由里使用。LND 的 router 服务（lnrpc/routerrpc/router.proto，v0.19.0-beta）里还有另一对接口：XAddLocalChanAliases 与 XDeleteLocalChanAliases，它们处理的是完全不同的本地账。

不通知对端在时间线上的代价

把注释里那句话推到实际时间线上：双方节点先后调用 XAddLocalChanAliases 写入同一映射，别名此后在两家节点之间可用；若一方重装清库而别名账没进备份，另一方继续按旧别名安排路由，失败会表现为一侧找不到映射，而另一侧没有任何报错可查——因为消息面从头到尾没有同步过。删除同理：单方 XDeleteLocalChanAliases 之后，对端若按旧账路由付款，要等它自己的映射也清掉才会停。这对接口把同步责任留给了人：两侧行为要靠共同配置、初始化脚本或变更流程对齐，指望协议消息自动带过去是不存在的。

上线前的三条自检

别名只用于内部记账还是参与路由解析——参与解析就必须双端成对写入；别名映射有没有进备份方案——它是本地账，节点没了它也没了；工具链在版本升级后是否继续认这个接口——实验性接口没有长期保留承诺。对账脚本里把「别名全集」当状态快照落盘，每次增删后比对差集，比只信调用返回值可靠。

添加：返回全集，但不出门

proto 注释把 XAddLocalChanAliases 的语义写得很满，关键信息有四条。其一，它是一个实验性接口，为一组通道创建新的 SCID 别名映射。其二，调用成功后返回的不是你刚加的那几个，而是这次添加操作之后别名管理器里的最终全集——对账脚本直接拿响应当最新状态表用即可。其三，也是最要紧的边界：这是仅本地存储的别名，不会通过任何消息告知通道对端；因此注释明确，想通过这样的别名路由，前提是通道对面也在它自己的节点上调用同一个接口。其四，如果某个别名已经存在于账上，这次添加返回错误而不是静默合并——重复添加被当作需要人看一眼的异常。

删除：同样静默

XDeleteLocalChanAliases 删除一组别名映射，同样返回操作后的完整别名集，同样不向通道对端发送任何消息。换句话说，这对接口像两个节点各自维护的一本私账：你记下的别名映射，对面的节点默认并不知情；两边的账本要靠约定或外部流程对齐，对端没记录时，走这个别名付款并不会因为你单方面的添加而突然成功。

什么时候值得用它

典型场景是给自己和长期对端之间的一套通道起稳定可读的本地名字，把短通道 ID 随区块高度变化的漂移挡在内部记账层，供自建路由工具、审计脚本按别名归组。它与协商型假门牌的差别在于：后者改变付款方眼中你的门牌，后者只改变你自己系统内部的门牌。实验性接口的身份也意味着行为与字段可能在后续版本变化，接入生产前请固定版本并做回归。

风险提示

再补一条排障线索：路由解析到别名失败时，报错出现在找不到映射的一方，排查顺序应该是先确认双方映射都在（各查一次本地账），再看版本是否支持，最后才是通道本身。跳过前两步直接查通道，往往查完一无所获。

另外，别名映射属于可重建的配置而非密钥材料——丢了可以重新写入，不涉及资金安全。把它和密钥类数据的备份优先级区分开，能省掉不少不必要的恐慌性操作。

别名只是记账标识，不改变通道资金的真实状态；把付款逻辑绑在未与对端对齐的别名上，可能造成路由失败的排查成本。本文不构成投资建议。