Bitcoin Core 的参数默认值大多写死在源码里，平时谁也看不到；只有两个场景会逼着人直面它们：一是节点行为”和预期不一样”要查原因，二是硬件资源受限要主动改默认。v31.0 里有一组参数的默认值不在 init.cpp，而被挪进了内核层的头文件——内存池三兄弟就是典型：默认上限 300 MB、默认过期时间 336 小时（两周）、纯区块模式（blocksonly）下自动压到 5 MB。这些数字定义在 kernel/mempool_options.h，改一个就会连锁影响另外两个的行为。
先看 300 MB 这个上限怎么起作用。内存池不是无限蓄水池：当交易总量逼近上限，节点开始按费率从低到高驱逐交易。这意味着一台默认配置的节点，在费用高峰期看到的”全网未确认交易”只是费率排得上号的头部——低费交易在别的节点池子里排队，你的节点根本不知道它们存在。getmempoolinfo 里的 mempoolminfee 字段是这件事的温度计：官方文档写明它是”交易被接受所需的最低费率，取 minrelaytxfee 与内存池当前最低费率的较大值”。平时它等于中继地板费率，一旦高峰期被抬到明显高于地板，就是在告诉你”低于这个费的交易我这不收”——此刻池子里的平均费率因此被系统性抬高。做费用估算分析的人如果只盯池子平均值而不看 mempoolminfee 是否被抬高，会把”低费样本被挤出”误读成”大家愿意多付”。
336 小时的过期时间解决另一个问题：一笔一直没被打包的低费交易，会在你节点内存池里赖多久？默认答案是最长两周，但有两个前置条件：一是它的父交易还活着（否则它作为孤儿早被清走），二是内存池没挤到提前驱逐它。两周这个量级配合节点的周期性重发机制，覆盖了低费交易长期滞留的极端场景。改小它没有收益——被驱逐的交易只是从你这消失，还会被别的节点再广播回来；改大它则在高峰期多占内存。绝大多数用户两头都不该动。
第三兄弟常被忽略：开了 -blocksonly 之后，-maxmempool 会被自动压到 5 MB，日志里写明这次参数联动。逻辑很直白：blocksonly 节点根本不中继交易，内存池只是偶尔从 RPC 进来的交易的暂存区，给它 300 MB 纯属浪费。同一轮参数联动还顺手关掉 -walletbroadcast——钱包不再自动广播交易，因为对端本来就被禁止转发交易。这是个容易踩的坑：有人为了省带宽开了 blocksonly，之后发现钱包付款”永远未确认”，原因不在钱包，在这条联动。日志里那句 parameter interaction 是唯一线索。
最后说说改默认的代价账。内存池和数据库缓存共享一块预算：-dbcache 的帮助文本明确写着”未使用的内存池内存会共享给这个缓存”。所以把 maxmempool 从 300 调到 1000，不只是多占 700 MB 标称值——它抢走的是 UTXO 集缓存的空间，同步和查账都会变慢。反过来小内存机器把 maxmempool 调小、dbcache 调大，是社区常用的减配配方，代价是池子不完整的时间更多。判断标准只有一个：这台节点的用途是什么。只做自己钱包的后端，池子残缺无所谓；跑区块浏览器或费用估算服务，宁可加内存也别缩池子。默认值不是最优值，它只是”给大多数人不出错”的值——而源码把每个默认写在哪一行都留了记录，查它比猜它便宜得多。
风险提示：参数默认值以 Bitcoin Core v31.0 源码为准，版本升级可能调整；调整参数不当可能导致节点功能受损，本文不构成运维或投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。