LND 的账本放在哪个引擎里：channel.db、channel.sqlite 与外部数据库

闪电节点最怕的一件事是账本损坏：本地数据库记录着每条通道的最新状态和撤销数据，丢一份等于把资金安全押在”对手方不会作弊”上。引擎选型因此不是性能话题而是安全问题。本文按 LND v0.19.0-beta 源码核对 LND 的账本到底存在哪些文件里，以及换后端时哪些运维动作必须跟着变。

一、默认答案：一个文件，channel.db

不指定任何外部数据库时，LND 用内嵌的键值引擎（BoltDB），全部账本写进数据目录下 data/chain/bitcoin/mainnet/channel.db 这一个文件——源码常量 ChannelDBName 定义的文件名。单文件内嵌的好处是部署简单：没有独立数据库进程、没有网络认证配置，备份就是把文件（连同它的一致性要求）复制一份。代价也一样明显：单文件写入在通道数量大、HTLC 频繁进出时可能成为节点瓶颈，文件本体的损坏半径也是整本账。

二、文件型替代：channel.sqlite

把后端切到 SQLite，账本落进同目录的 channel.sqlite（源码常量 SqliteChannelDBName）。对很多运维者来说 SQLite 的吸引力在于工具链：标准 SQL、单文件依旧、能用常见工具离线查询体检。但这里有条安全边界必须写清：闪电的账本写入依赖数据库的崩溃一致性语义，把 SQLite 调到牺牲耐久性换性能的同步模式，等于在断电场景下赌本地状态回滚不丢撤销数据——那种模式的名字里带着 unsafe 前缀不是随便起的。闪电账本的正确取舍是耐久优先、性能其次。

三、外置数据库：当单节点长成大部署

对多实例、大规模路由节点，LND 支持把账本交给外部数据库引擎。配置上从”文件路径”变成”连接串加认证信息”，拓扑上多了一个必须高可用的独立服务。连锁变化比看起来多：备份从”复制一个文件”变成数据库转储加时间一致性快照；权限从”文件属主”变成账号与网络访问面，数据库端口暴露在内网就等于给账本文件开了旁路；恢复演练必须按新引擎的方式重做一遍，并且和静态通道备份（SCB）对账验证。源码里内嵌后端与外置后端共存的设计意图，是给”一台机器上的小节点”和”一个组织的路由服务”两套运维模型都留通路——但账本一致性要求对两者是同一条标准。

四、引擎之外，备份语义没变过

不管换哪个后端，静态通道备份文件仍是最后一道防线：它是加密打包的通道状态快照，丢了本地账本时用它重建。换引擎改变的是备份的形状和恢复的工具，不改变”任何一次通道开通后都要落一份新备份”的节奏——SCB 文件覆盖旧备份前确认新备份可读，这条纪律与数据库选谁无关。选型问题的正常答案其实很朴素：个人节点用默认内嵌引擎、盯好磁盘，规模路由再考虑外置并同步升级运维能力。比选型更重要的，是把当前引擎的崩溃一致性语义、备份路径和恢复步骤写进运维手册并演练过。

五、换引擎之前先跑通的两件小事

无论最终选哪个后端，有两件不依赖引擎选择的事值得先做。第一是恢复演练：从备份文件起一个隔离环境，验证节点能重新同步通道状态、余额读数与主库一致——没演练过的备份等于没有备份，换引擎只会让这一步更需要重做。第二是数据完整性巡检：把数据库的离线校验命令纳入例行任务，在损坏发生前发现异常页与校验和不一致，比在恢复时才发现备份同样损坏要好得多。引擎迁移本身的技术路径是标准的：用导出工具从旧后端读、向新后端写，全程节点必须离线、迁移后先以只读方式核对通道数量与每通道状态摘要再对外开放付款。这些步骤听起来繁琐，但它们正是闪电账本的特殊性要求的谨慎：这里的数据库损坏不是普通数据丢失，而是资金安全边界的丢失，任何引擎选项都不要为那点性能数字放弃这一点。

本文所有事实按 LND v0.19.0-beta 源码核对，数据库后端的支持范围随版本变化，以对应版本源码与官方文档为准。文中内容仅为技术说明，不构成任何投资建议。