钱包文件从 Berkeley DB 搬到 SQLite：换引擎后的备份、验收与回退

一、一场持续推进的换引擎

比特币核心的钱包存储长期依赖 Berkeley DB。随着描述符钱包落地，新钱包把底层引擎换成了单文件 SQLite，并把钱包类型（是否用描述符）与存储格式（用哪个引擎）分开陈述。方向清晰：新建钱包默认就是描述符加 SQLite；旧式钱包靠 migratewallet 迁入；旧引擎的支持则按版本生命周期逐步退场，每个大版本的发布说明都会写明哪些版本进入维护末期，具体退场时点以你使用版本的说明为准。对用户，这场换引擎最先感知的不是命令而是文件形态：SQLite 钱包是数据目录里孤零零一个 .sqlite 文件；BDB 钱包则是一整套带 db.0 与日志文件的目录，冷备漏掉任何一个日志都可能让恢复失败。

二、先确认自己站在哪一侧

打开 getwalletinfo 看两个字段：format 为 sqlite 即已是新引擎；descriptors 为 true 说明是描述符钱包。两者都是好消息，钱包文件从此单文件可管：停钱包后整文件拷贝就是可用备份。仍在 BDB 一侧的钱包，备份请走 backupwallet 的打包流——它理解事务与日志，直接复制目录属于外行姿势。另有一条常被忽略：SQLite 钱包运行中对文件做快照式备份同样危险，日志没落盘的部分不在你拷走的字节里。备份语义换轨之后，“定期整目录压缩”的老习惯从加分项变成了隐患。

三、迁移验收单与回退

停机、冷备份整套钱包文件、执行迁移，然后逐项核对：listwallets 应列出主钱包与可能存在的 _watchonly 钱包；主钱包的 format 与 descriptors 两个字段应双双翻转；余额与新钱包加旁观钱包对账，multisig 部分去 _watchonly 里找；用小额收发一笔确认签名路径正常；最后对每个新钱包各做一次 backupwallet。回退姿势是把冷备份原样放回去——迁移只是把你的旧文件改名只读留存，真正能救命的始终是你自己那份迁移前的拷贝，而不是那个被改名的残骸。

四、别硬迁的情况

老硬件钱包配旧派生路径的钱包，迁移后可能出现第三方工具不认描述符的兼容缝隙；这类场景更稳的路线是先不迁，或导出后在新钱包按描述符重建视图，让旧钱包转成只读档案继续记账。换引擎是基础卫生，收益在备份可靠性与生态兼容上，不在版本号上；把验收单走完再宣布成功，比抢在版本公告前一天迁移有价值得多。

五、命令行党还有一条工具线路

不想动运行中钱包的人可以用离线工具：bitcoin-wallet 的 dump 系列命令能把旧式钱包文件导出成文本清单，再用创建命令按清单重建为新格式——全程不启动节点，适合处理冷备份目录里的祖传文件，或在不确认在线迁移结果时先做只读体检。另一条验收命令常被忽略：listdescriptors 会把钱包全部描述符连同校验和导出，这是唯一能把”这个钱包到底管哪些地址”说完整的机器可读清单；迁移前后各导一份、差异对比一遍，比盯着图形界面余额截图可靠得多。注意导出文件等同半本账本，不含私钥的公开描述符也足够让分析方给你的地址画图谱，存放与销毁按敏感文件对待，别随手丢进邮件附件。

本文内容仅供信息与教育参考，不构成投资建议、法律或税务意见，也不构成对任何产品或服务的推荐。比特币与闪电网络操作不可逆，涉及资产操作前请自行核实关键参数并评估风险。