比特币核心开着 -rest 时，/rest/mempool/info 和 /rest/mempool/contents 这两个 HTTP 端点把内存池的总量指标与逐单明细直接摊在 URL 上，还支持 verbose 与 mempool_sequence 两个查询参数。本文按 v31.0 源码拆解端点行为、参数互斥关系，以及它没有鉴权这层事实带来的暴露面。

比特币核心 v31 把内存池的条数与体积限额从祖先后代链换成交易簇，随之而来的是新代号 too-large-cluster。它在源码里出现在四处，返回类别分为交易级策略与整包策略两种，处置动作完全不同。本文对齐新旧参数、默认值与硬上限，并解释为什么这项检查必须放在替换登记之后。

带相对时间锁的交易进不了内存池，节点给的代号是 non-BIP68-final。比特币核心 v31.0 的判定函数直接用链顶高度加一作为参照，因为内存池里放的应该是下一个块就能采纳的交易。本文对照区块层的 bad-txns-nonfinal，讲清绝对锁与相对锁两套代号的分工，以及写相对锁时最容易贴错边界的地方。

父交易还没到，和引用的输出已经被别人花掉，在比特币核心 v31.0 里共用同一个拒绝代号 bad-txns-inputs-missingorspent。本文从源码出发说明节点为什么不做区分、TX_MISSING_INPUTS 如何让交易获得留在孤儿交易库的资格，以及钱包和自建服务应按什么顺序排查这一类广播失败。

重复广播同一笔交易时，比特币核心 v31.0 不一定去磁盘上追根究底，而是先拿这笔交易自己会产生的输出点去问一遍内存缓存，命中就直接返回冲突类的 txn-already-known。本文讲清这条快路径的判定顺序、它只查缓存带来的覆盖面缺口，以及它与输入缺失类报错在处置动作上的分工。

集群内存池时代，RBF 第五条规则限制一笔替换直接冲突的唯一簇数量不超过 100，超出即以 too many conflicting clusters 拒绝。拆解按簇计量的原因、与包上限的分界和官方测试的边界用例。以 v31.0 源码为准。

testmempoolaccept 与 submitpackage 一次能吃多少交易由 MAX_PACKAGE_COUNT（25 笔）和 MAX_PACKAGE_WEIGHT（404000 权重）决定。拆解这两个数字与标准交易权重、内存池簇上限之间的对齐关系和两类报错现场。以 v31.0 源码为准。

v31.0 的簇内存池用 `-limitclustercount` 与 `-limitclustersize` 两个新限额取代了祖先后代限制，旧参数 `-limitancestorcount` 等只剩钱包选币一个用途。本文按 v31.0 源码逐项拆这四个参数的现状、默认值与误配后果。

以太坊在 2019 年 1 月提出的 EIP-1681 想给交易加一个可选的 valid-until 字段，让过期后自动失效，解决交易在内存池排队数天仍被执行、以及将来清理尘埃账户时的重放问题。这份提案如今处于 Stagnant 停摆状态，从未进入主网。本文按原文拆解它的两阶段上线设计、为什么选择 UTC 墙钟时间而不是区块高度，以及普通用户如何理解这笔还没生效的设想。

集群内存池让排序、驱逐与 RBF 替换共用同一把尺子——feerate diagram。v31.0 新增 getmempoolfeeratediagram RPC 输出累计 weight 与累计费用拐点，并把阶梯严格改善写进替换规则第 6 条。本文讲图怎么画、返回值怎么读。