每次重启比特币全节点，在途的未确认交易会被忘掉吗？这个问题背后就是 persistmempool 参数。先给经过源码核对的结论：在比特币核心 v31.0 里，它的默认值是开启——定义在 src/node/mempool_persist_args.h 的常量 DEFAULT_PERSIST_MEMPOOL{true}，也就是说，你什么都不配置，节点也会在正常退出时把内存池内容写进数据目录（网络子目录）下的 mempool.dat，下次启动再装载回来。帮助文本的原话是 Whether to save the mempool on shutdown and load on restart。
要理解这个默认值为什么合理，得先看清重启节点到底丢了什么。内存池里存的是已被节点验收、尚未进块的交易。交易本身还散落在全网其他节点的内存池中，早晚会被打包，所以持久化解决的不是资金安全问题，而是本机体验问题：其一，钱包界面里刚发出的交易可能在重启后暂时查不到，要等它从 peers 处重新同步回来；其二，本地钱包的选币逻辑若看不见这些在途交易占用的 UTXO，管理员一急手动重发，就会构造出双花冲突。开启持久化后，这些状态跟着文件走，重启近乎无感。
机制细节上，节点关闭时把当前内存池中的交易连同入口依赖序列化进 mempool.dat；启动时逐条重新走一遍标准验收，而不是无条件信任文件内容——过期费率的交易、依赖已进块输入的残单会在加载时被静默丢弃。若文件本身损坏，日志会留下一行 Failed to deserialize mempool data 然后照常启动，节点不会因这份缓存拒绝工作。它也是文件级容错最友好的一层：删掉 mempool.dat 顶多回到”冷启动”体验，不会伤及链上数据。
与之相邻的是 savemempool RPC：前者是关机时的自动快照，后者允许你随时手动落盘。升级或迁移节点前手动存一份，比只依赖关机写入更稳，因为强杀进程、断电都不会触发那份自动保存——若你习惯用 kill -9 停节点，这个默认开启的参数实际上形同虚设。另有一个过渡开关 persistmempoolv1，控制写入旧版（版本一）还是当前（版本二）文件格式，帮助文本明确注明这是未来会移除的临时选项，且它自 v27 版本才随参数表出现，旧版本不认识它。
常见误区有三类。一是以为关掉它能省磁盘：文件体积与内存池上限（默认 300 MB 量级）相关，通常远小于链上数据本身，为省这点空间关掉它得不偿失。二是以为它能保证全网仍记得你的低费率交易：文件只帮本机恢复视图，若全网只有你见过某笔交易，重启后仍需手动重发。三是把它与 persistmempoolv1 混为一谈，或把文件当作可以在陌生节点间随意搬运的热启动包——交易会被重新验收，但文件里夹带的地址关联会污染接收方的关联分析。
隐私面提醒：mempool.dat 内含未确认交易的明文内容，他人可读该文件即能窥见你的支付尝试与地址关联，多人共用主机时应收紧数据目录权限。默认值、文件格式（当前为版本二）都可能随版本演进，本文结论对应 v31.0 源码，动手前请以你所用版本的 -help 与发行说明复核。
最后把这套机制放进一次完整的升级演练里走一遍。设想你要把跑了几周的老节点升级到新版本：先在维护窗口前用 savemempool 手动存一份当前内存池，再等一笔在途交易确认或做好它滞留的预期；正常 stop 节点，确认进程退出而非强杀；替换二进制后启动，用 RPC 查内存池规模与几笔关心的交易是否仍在跟踪。如果升级跨越了序列化格式的过渡期，新版本可能按当前格式读写文件，而旧版本只认旧格式——这正是 persistmempoolv1 存在的意义：临时让节点用旧版格式写文件，方便降级回滚时旧二进制还能读懂。演练的意义在于把”重启后一切是否正常”从祈祷变成清单，而这个参数只是清单上安静的一行。
还有一个容易被忽略的运维事实：内存池的装载与淘汰受同一个内存池上限约束，升级前后如果你同时改过容量参数，重启加载历史交易时可能触发一轮集中淘汰，日志里会留下相关痕迹。这种淘汰不代表故障，只是文件里的交易在新限额下排不进队。理解这一点，升级后的检查才不会把正常的限额行为误读成数据丢失。
风险提示：参数或文件操作不当可能造成重启后在途状态丢失，升级与迁移前请备份数据目录。本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。