节点收了交易，却说”还没广播”
日常使用中有一个隐蔽的失败模式：钱包把交易交给了自己的节点，节点也接受了它——验证通过、进了内存池，但因为网络抖动、刚上线还没建立足够连接等原因，交易没能推送给任何邻居节点。它静静躺在本地内存池里，看起来”已发送”，实际在网络上等于不存在。比特币核心从 0.21 版本起为这种情况加了显式机制：广播失败的交易被移入一个叫 unbroadcast set 的集合，节点不再反复骚扰邻居，但会在有对端通过 getdata 主动询问时把交易交出去，并持续尝试补广播，直到成功或交易被挖出。
它在数据里长什么样
这个状态对用户不是不可见。getmempoolinfo 的返回里有一个 unbroadcastcount 字段，表示本地持有未广播交易的数量；getrawmempool 加 verbose 时，每笔交易可以带一个 unbroadcast 布尔标记。如果你的节点内存池里有一笔 unbroadcast 为真的交易，正确解读是”这笔交易可能只有你自己的节点知道”，它不会出现在别人的内存池上，也就几乎不可能在下一块里被打包。排查卡单时可以按这个顺序走：先看交易是否在你本地内存池（见 getrawmempool怎么读取内存池？），再看它是否标了 unbroadcast，最后才怀疑费用不足。
与”低费率卡单”的分工
未确认交易的常见结局有三种——等待、加速、被丢弃，路径分析见 比特币交易一直未确认怎么办？等待、RBF 加速与被丢弃的三种结局。unbroadcast 是排在它们前面的另一种故障：费用够、规则合规，只是没送出去。分辨方法很直接，一笔未确认交易如果在整个网络的大内存池聚合视图里查不到、只有你的节点知道，那它属于广播故障；如果全网都能看到却不进块，才是费用问题，此时的工具是 RBF 或 CPFP，取舍见 比特币RBF和CPFP怎么选？。
钱包为什么信任”自己广播”
传统钱包流程是构造、签名、广播三件事在同一进程完成；节点钱包则把签名（冷环境）与广播（本节点）解耦。这种解耦让交易的生命周期所有权归节点：钱包负责”造出来”，节点负责”送出去并对结果负责”，unbroadcast 集合就是这个责任交接的兜底条款。对普通用户的实操含义有二：其一，用节点做钱包后端时，付款后值得去内存池视图确认交易真在网络里流转，而不是只看”已签名”；其二，任何声称”已发送但网络查无此单”的场景，先查本机节点连接数与广播状态，这是最常见的自欺源头。内存池生命周期细节见 未确认交易在内存池能活多久：过期、淘汰与驱逐规则。
小结
unbroadcast 是节点给”接收成功、发送失败”这类灰色状态立的户口：不静默丢弃，也不再轰炸网络，改为被动应答加持续补投。它把一种过去只能靠人肉重发的故障变成了可查询、可自愈的流程。日常价值一句话：交易没进块时，先分清是没送出去，还是送出去没人理——两种卡单的药方完全不同。本文不构成投资建议。
手动补一枪
不同客户端的重发入口不同：核心钱包类后端有 resendwallettransactions 类接口可手动触发对端推送，第三方钱包则通常把重发逻辑包在联网重试里。通用自查三步：第一步确认交易仍在本地内存池（见 getrawmempool怎么读取内存池？），第二步看节点对等连接数是否健康，零连接时什么广播机制都无能为力，第三步确认本地节点版本不早于引入该机制的 0.21——更早版本的重试依赖钱包层的定时重发，断网时段的交易可能既没广播也没补投。
重启之后：unbroadcast 集合不持久化
还有一个运维层面的细节值得提前知道：unbroadcast 集合是内存态，节点重启后清空。这带来两个推论。其一，如果你的节点在广播拥塞期间重启，原本挂在集合里的交易不会自动重新排队，节点会在启动后把内存池交易重新向对端公告一遍，实际效果接近”自动重做一次”，但时机会被重启流程推迟；依赖自动补偿的自动化脚本最好把”重启后核对广播状态”写进流程而不是信任记忆。其二，排查跨重启的卡单时，别忘了把节点的重启时间线放进事故时间轴——很多”交易突然又活了”的现象，背后的真实原因只是节点重启触发了一次全量重新公告，与对端网络恢复恰好撞在一起。钱包侧的定时重发（钱包会周期性重广播未确认交易）也是同族机制，两条重发路径叠加时交易通常会在几分钟内补齐传播，理解谁在替你重试，比手动反复点”加速”更接近问题本质。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。