旧式钱包搬家记：migratewallet 把钱包变成哪三个文件

一、一次迁移，拆出一套文件

比特币核心曾把私钥、地址簿和交易记录存在 Berkeley DB 格式的单一钱包目录里，这类钱包被称为旧式钱包。0.21 版本引入了以描述符为核心的新钱包格式，22.0 则补上了 migratewallet 这条命令，专门负责把旧式钱包整体搬进新格式。运行一次它，原文件并不会就地变形，而是生成一套新账本：主钱包改用描述符描述每类输出”长什么样、怎么花”，存储引擎也顺势换成 SQLite；如果旧钱包里存在没有私钥、只能旁观的脚本——最常见的是你导入过的 multisig 地址——这部分会被剥离出来，另存为一个带 _watchonly 后缀的独立钱包；原来的旧文件则被改名成只读备份留在原地，从此不再写入。

二、watchonly 为什么要单居

新钱包的一切围绕描述符组织：一条描述符既能批量生成地址又能精确解析脚本，钱包靠它重算余额与归属。旧式钱包里的 watchonly 脚本往往凑不出完整描述符——可能缺公钥信息，也可能派生路径不明。与其勉强塞进主钱包污染描述符表，不如让它们住进一个独立的旁观钱包继续记账，这就是拆分的技术动机。副作用是可见性：升级后不少用户以为钱丢了，其实是 multisig 余额被分流进了 _watchonly 钱包，先跑一遍 listwallets 数数钱包数量，多数惊慌当场就能消解。

三、迁移之后核对什么

第一眼看 getwalletinfo 的 format 字段，迁移成功的新钱包显示为 SQLite。第二看余额拆分：把主钱包与 watchonly 钱包的余额相加，对照迁移前总额，两跳确认 multisig 部分没有静默蒸发。第三抽查历史：迁移会把密钥、派生路径与脚本映射整理进描述符表，交易记录原样保留，但地址簿里的标签偶有错位，值得随机点开几笔核对。确认无误后立刻对每个新钱包分别做一次 backupwallet——那份被改名的旧文件只是保险丝，不是长期备份。真要回退，姿势简单粗暴：停节点，删掉生成的新钱包，把旧文件改回原名。前提是迁移之后你没有再用旧钱包产生新交易，否则回退就会丢掉这段增量。

四、不搬家会怎样，谁不该硬迁

旧式钱包不会一夜消失，但它站在版本生命周期的下坡路上：每个大版本发布时都会公告哪些版本进入维护末期、哪些旧组件不再获得积极维护，Berkeley DB 相关代码就在逐步退场的名单方向上。遇到只支持描述符的新硬件或新工具时，硬迁可能得不偿失——更稳的路线是用工具从旧钱包导出私钥或地址信息，在新格式钱包里按描述符重建视图，让旧文件安静退休成只读档案。迁移是基础卫生，不是必须抢跑的军备赛：先备份、再迁移、后核对，三步顺序错了，才是这条命令唯一真正危险的用法。

五、两个顺手要做的动作

迁移之外，日常建钱包的默认值也值得核对一次：createwallet 的描述符参数在新版本里默认开启，图形界面新建钱包时的”描述符钱包”勾选框同理——如果你的习惯是脚本化创建且显式传了关闭，那你其实一直在造旧式钱包，迁移清单上会多出一位幽灵。另一个动作是存档迁移日志：迁移过程对每个脚本的处理（转换成功、移入旁观、放弃迁移）都会写进钱包日志，watchonly 余额对不上账时，那份日志是唯一逐条说明”哪些脚本没能变成描述符”的官方证词，比在论坛猜原因快得多。

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