一条 getdata 与一批包：比特币把”一次提交多少笔交易”卡在 25 笔和 404000 权重

比特币网络里很多对话看起来是”一次给一笔”，但实际允许一次给一组：testmempoolaccept 可以一次送进多笔交易做预检，submitpackage 可以一次提交一个交易包，子父绑定的 CPFP 场景尤其需要这种”成批”能力。这个”一批”不是无限大的，源码给两条硬指标卡了上限：一笔包最多 25 笔交易，整包总权重最多 404000。本文全部以 Bitcoin Core v31.0 源码为准。

上限写死在包策略头文件里

在 src/policy/packages.h 里有两个常量。一个是 MAX_PACKAGE_COUNT，取值为 25，注释写明这是”一笔包中交易数量的默认上限”。另一个是 MAX_PACKAGE_WEIGHT，取值为 404000（写作 404'000，是 C++ 的数字分隔写法，数值就是四十万零四千）。包验证的第一道关卡就检查这两条：交易数量超过 MAX_PACKAGE_COUNT 或者总权重超过 MAX_PACKAGE_WEIGHT，整包直接按策略拒绝。RPC 层也复用同一个数字：testmempoolaccept 的帮助文本会告诉你”允许的最大交易数量是 25”，而代码里一旦传入的数组长度小于 1 或大于 25，就直接抛出参数错误。

为什么是 404000，而不是四十万

MAX_PACKAGE_WEIGHT 和单个标准交易的上限、以及区块权重上限是刻意对齐的。源码里有一句 static_assert(MAX_PACKAGE_WEIGHT >= MAX_STANDARD_TX_WEIGHT)——包的权重预算必须至少不小于一个标准交易允许的权重（MAX_STANDARD_TX_WEIGHT 为 400000），否则连”一笔我们本来会单独接受的交易”都塞不进包，规则自相矛盾。之所以留到 404000 而不是正好 400000，注释解释是为了容纳带签名操作计价的那部分余量，让那些本来会被单独接受的更宽的交易，不因打包而反被拒。同一文件还断言：包上限必须落在内存池的簇（cluster）大小限制之内——包是簇的一部分，不能反过来比簇还大。

二十五笔这个数量级怎么理解

25 这个数字来自”一笔交易最多能带多少依赖”的现实权衡，而不是某个协议神圣常数。它保证了一次成批提交所需做的验证工作是有界的：每加一笔，节点要做的祖先/后代关系检查、费用核算都是叠加的，卡一个数量上限能把单次提交的开销钉在可预测范围内。同一个 25 也远低于内存池簇默认允许的 64 笔连接上限——也就是说，你自己成批提交（包）比网络里自然长出一个大簇要更保守，这是有意为之。

触发上限时的现场

如果你一次塞进第 26 笔，或整包权重刚过 404000，会看到两类不同报错。走 RPC 数组（如 testmempoolaccept）时，是参数层面的”数组必须包含 1 到 25 个交易”；走包提交路径时，则是一个包级别的策略拒绝（PCKG_POLICY，含义是包本身违规，例如交易太多）。排障时区分这两条很有用：前者说明你调用姿势或切分不对，后者说明你的依赖图确实太肥，需要考虑拆包、减少子父层数，或者接受分批提交。

常见误区

一是把 25 当成”链上一笔交易最多 25 个输入”，混淆了包里的交易数和交易里的输入数，两者毫无关系。二是以为这 25 笔可以任意乱序提交：包要求父交易排在子交易之前，顺序错了同样过不了。三是把 404000 当区块上限（400 万权重单位），其实它只是”一次成批提交”的单包预算，比单个区块小一个数量级，专门用来给批量校验封顶。理解这两条数字，本质上是理解节点愿意为”你的一次调用”预付多少验证资源。

风险提示：本文为节点策略与 RPC 机制科普，具体数值以 Bitcoin Core 当前版本源码为准，可能随版本调整；不构成交易确认时效承诺或投资建议。