比特币交易的输入条数有没有上限？三层规则给出三个答案

有人问：一笔比特币交易最多能带多少个输入？直觉答案可能是”没有限制”，也有人说”肯定有条数常量”。都差一点。真实情况是分层的：共识规则确实不看条数，反序列化却天然封了一个巨大的天花板，标准政策再把现实数字砍小好几个数量级。按三层各自算一遍，这笔账才清楚。

共识层：没有条数检查

consensus/tx_check.cpp 里的基础校验清单：输入非空、输出非空、交易不能大到非见证体积乘放大系数超过区块权重、输出金额不溢出、输入不得重复。注意没有任何一行在数输入个数。理论上共识只要求所有输入加起来不超过 2100 万枚的账面约束——输入条数本身不是共识变量。

协议层：被序列化格式顺手封死

条数的真正硬上限藏在编码里。交易序列化的变长整数用紧凑整数（CompactSize）表示，反序列化时 ReadCompactSize 对带范围检查的读取设定了 MAX_SIZE，值为 0x02000000，即三千三百五十余万。条数字段声明超过这个值，字节流直接抛异常，连交易对象都构造不出来。这是一个”防御性上限”：它不是为交易设计的功能限额，而是防止恶意长度字段触发天文数字内存分配的护栏。所以最准确的表述是：输入条数没有协议规定，但存在约 3354 万的技术上限。

政策层：先被标准性拒之门外

真实世界里碰到的墙远比这个低。标准交易有权重上限（默认四十万权重），单个输入哪怕只占约 148 权重字节，粗算下来几千个输入就把预算吃光；标准交易还各自有 sigops 预算，脚本签名操作逐输入累加，同样先撞线。 Dust 规则和费率门槛则保证几千个输入凑出来的交易必须付出真实成本。换句话说：政策层允许的交易形态，天然装不下接近上限的输入数。

一条可以自查的验证路径

这套三层账不用背，能自己验。共识层的条数无检查：测试网构造一笔带几十个输入的巨型交易，testmempoolaccept 会按标准性拒绝它，但矿工手动塞块依旧合法。政策层的墙：同一笔交易逐步增加输入，费率和 sigops 会让它在某个点开始报 nonstandard 或超权重，那个点远低于协议上限。协议层的地板：用十六进制把输入计数字段改成接近 0x02000000 的声明值再反序列化，解码直接失败——上限是护栏而非功能。三层各自独立、互不背书，这正是”没有上限的上限”这个说法的准确含义。

巨型输入的真实约束：成本

把上面的账合起来看，唯一值得关心的约束是钱。合并大额 UTXO 集合（比如交易所清合并、混本后的归拢）时每多一个输入就多花一次字节的费，输入越多交易越大，费率竞争里越吃亏。这就是钱包做coin selection 时永远倾向于少输入的原因，也是”大 UTXO 更值钱”这种市场直觉的来源——它省的是未来的字节费。

三个数字一起记

最后把三层的答案并排放：共识层——条数无检查，只有体积、金额、重复输入三类校验；协议层——反序列化护栏把任何声明值封在约三千三百五十万；政策层——权重与 sigops 预算实际封顶在数千条量级。三层由松到紧，越靠近用户的钱包行为约束越强，这恰好是比特币规则设计的一贯风格：共识层宽进、政策层严出、市场层定价。

需要强调：构造接近任何层上限的交易只有在测试网自娱的意义；主网上这类交易要么进不了内存池，要么成为费率笑话。另外，“条数不设限”不等于”条数没有隐私含义”——输入条数多的交易会在链上暴露该地址持有的UTXO碎片数量，属于分析人员常用的聚类线索，这也是钱包合并策略同时是费用策略和隐私策略的原因。关于输入结构与隐私、费用的更多权衡属于机制讨论，不构成任何操作或投资建议。