一个节点管好几个钱包：createwallet、loadwallet 与启动清单的三本账

一、磁盘上的钱包和运行中的钱包是两本账

比特币核心的钱包是数据目录下一个个独立的目录或文件。节点启动时按配置装载若干个，其余的静静躺在磁盘上。listwalletdir 列磁盘上有什么，listwallets 列当前装载了什么，两者的差集就是”存在但没在服务”的钱包。很多”我的钱包不见了”的求助其实只是这一步没对上：文件还在，只是没装载。

二、createwallet：出生时就定好的几件事

createwallet 除了名字，还有几个出生设置：disable_private_keys 造纯观察钱包，只认账不花钱；blank 造空钱包，不带任何密钥，之后用 sethdseed 补种子；avoid_reuse 开启后，被花过的地址会被持续标记，查询余额时会把”脏币”分开统计——这个开关建议在建钱包时想清楚，因为描述符钱包创建后无法用图形界面轻松改判；descriptors 决定新钱包是否使用描述符架构，当前版本默认开启，造传统格式钱包需要额外打开 -deprecatedrpc=create_bdb，官方明确说传统钱包类型正在退役，未来版本将不支持创建和打开。名字建议一次定好带用途的命名，比如”长期冷备监控""日常小额”，之后所有命令都要靠它寻址。

三、loadwallet 的一个冷知识：启动参数会跟过来

loadwallet 把磁盘上的钱包目录装进运行中的节点。官方文档特别注明：bitcoind 启动时用的所有钱包类命令行选项，都会套用到这个新装载的钱包上。也就是说，如果主进程带着 -rescan 或某类开关启动，中途用 RPC 装载的钱包也会经历同样的处理。理解这条，才能解释”为什么加载一个老钱包卡了很久”——多半是触发了扫描。load_on_startup=true 会把钱包名写进节点的持久设置，下次启动自动装载；不想每次手动 load 的服务端就靠这个参数固定名单。

四、unloadwallet：退出服务但不碰文件

卸载只把钱包从内存中摘出，磁盘文件原样保留，随时可以 loadwallet 装回。文档还提醒：在带钱包名的 RPC 端点上再指定钱包名是非法组合——要么在默认端点调用时给出名字，要么在 /wallet/<名字> 端点上不带参数，二选一。要删钱包是另一回事：先得卸载，再移动或删除目录，顺序反了会报”钱包在用”。给钱包排班其实就是这一对动作的循环：装进来干活，用完请出去，减少同时暴露在服务下的密钥面。

五、备份账：每个钱包各记各的

多钱包最容易出的事故是以为备份了 A 就等于备份了全家。每个钱包的数据彼此独立，backupwallet 也只认当前选中的那个钱包。规则很朴素：任何改动密钥池或地址簿的操作之后——导入密钥、导入描述符、补.hd 种子——都要给那个钱包重新做一份备份，官方在 importdescriptors 等命令的说明里逐条写着”Requires a new wallet backup”。定期用 listwalletdir 对一遍磁盘清单、对每个在册钱包各留一份最近备份，这套纪律比任何单个命令的技巧都更能决定出事那天你能不能找回东西。

补充：命名与分层的实用建议

多钱包架构下值得坚持的三条纪律：一是钱包名当接口用，建钱包时就用用途命名并写进脚本变量，避免”wallet1、wallet2”半年后谁也说不清装的是什么；二是按风险分层，把长期持有的观察钱包、日常签名用的设备钱包、临时项目钱包分开，任何一层泄露都不牵连其他层的密钥面；三是变更即备份，把”改动过密钥池的钱包当天重做备份”写进日历而不是靠记性。清单化的维护动作在多钱包场景下的边际价值最高，因为事故形态从”一个钱包没备份”变成了”没人记得还有这个钱包”。