一笔交易在节点内存里到底能活多久
很多人遇到过这样的场景：发起一笔比特币转账之后一直没有确认，几天过去，区块浏览器上越来越难找到这笔交易，收款方一无所获，付款方钱包里那笔钱倒像是回来了。交易真的会死掉吗？这背后是节点内存管理的一条规则，-mempoolexpiry 和 -persistmempool 两个参数共同决定了一笔未确认交易在节点里的寿命。
过期时间：默认 336 小时
比特币的内存池不是账本，只是节点的待打包缓冲区。里面的交易没有链上期限，节点也没有义务永远替全网记着它们。比特币核心给每笔进入内存池的交易设了一个生存时钟：默认超过 336 小时（14 天）仍未被打包，节点就可以把它清除。这个默认值以常量形式写在核心代码里——按比特币核心 v31 配置参考与 master 分支内核文件 mempool_options.h 核对，DEFAULT_MEMPOOL_EXPIRY_HOURS 为 336。
除了到期清算，还有第二条更常见的驱逐路径：空间压力。内存池默认上限 300 兆字节，拥堵时节点按祖先费率先清除最不划算的交易，等不到十四天。所以你看到的交易消失，要么是到期，要么是被挤掉，两者都不是链上事件：交易花掉的 UTXO 从未真正被花费，你的钱仍在原处，可以重新发起一笔。
持久化：重启不等于失忆
为了不让节点每次重启都把未确认交易忘光，比特币核心默认开启 -persistmempool：正常退出时把内存池内容写入数据目录下的 mempool.dat，下次启动再装载回来，运行中也可以用 savemempool 命令手动落盘。这解释了一个常见现象：重启节点后，之前一直转发的低费交易还会被继续维护和重广播，因为记忆被恢复了。
要注意持久化保存的只是这台节点的记忆，不改变任何链上事实，也不保证交易还活着——重启后装载时同样会先做一遍标准性校验，早该失效的会被静默丢弃。importmempool 这类导入外部快照的操作，官方文档明确警告不要信任来源不明文件里的元数据。
对普通用户意味着什么
第一，未确认就等于没完成。任何以交易已广播为依据的交付、发货或记账，都应该以 txid 出现在某个区块、确认数达到约定值为准，而不是以某个节点或浏览器还显示它为凭。第二，交易被丢弃不等于资金损失：核对收款地址和金额没问题的前提下，钱包提示重新发起或走 RBF 加急即可；如果原交易之后突然在十四天内某个角落被打包，才构成真正的双花冲突，这时才需要仔细对账。第三，日常用户不需要动这两个参数；节点运维者调短过期时间，等于让自己的节点比全网更早放弃低费交易，只会降低自己在拥塞期的价值。交易费率与确认策略请始终以你使用的钱包和官方文档当前版本为准。以上内容只做机制说明，不构成任何投资或交易建议。
一个容易混淆的细节：过期时钟从什么时候起算
内存池条目的时间戳反映的是节点第一次见到这笔交易的大致时间，过期判断围绕这个入口时间展开。拥塞期常见的景象是：一笔低费交易在大内存池节点里还活着，在你家节点的默认 300MB 池子里早被挤掉了。两边都没错，也都不构成对交易的最终裁决——只要它花的那笔 UTXO 还没被别的交易真正消费，任何遵守标准的节点在任何时刻都还可能重新接受一份合规版本。
实操建议的排序
遇到交易长期不确认，先把 txid 放进两三个互不隶属的区块浏览器核对，再决定是否动作。若显示未进任何池，直接按原样重发或用钱包的重发功能；若确认还在部分节点的池里排队，评估当前费率后考虑 RBF 类加速；若显示曾在池里随后消失，那基本就是本文说过的到期或被驱逐，重发新交易即可，新交易的费率按发送时刻的市场估算重新给，不要照抄旧报价。整个过程里唯一不能省的动作，是重发前再次核对收款地址与原交易完全一致，避免把一次排队故障升级成一次转错。
为什么十四天是一个合理的折中
如果节点承诺永久保留未确认交易，任何人发一笔一聪的零费交易就能让全网替它永久记账，内存变成公共提款机。给记忆加上时间上限，同时允许本地持久化续期，是在抗骚扰与用户体验之间取的平衡：正常交易要么很快进块，要么在两周窗口内自然退场，攻击者想靠囤积未确认交易撑爆全网内存的成本因此变得不划算。理解这一点，也就理解了为什么交易消失是设计行为而不是系统缺陷。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。