Ethereum 待处理交易详解：Nonce、替换与取消

签署 Ethereum 交易后，钱包可以将它发送给执行客户端或交易服务。接受该交易的节点可能会将它转发给对等节点，区块提议者之后也可能将它纳入区块。在交易被纳入之前，它还没有改变规范链的状态。钱包或区块浏览器显示“待处理”，通常表示该服务知道这笔交易，但尚未在区块中观察到它；这并不代表全网有一个统一的交易队列。Ethereum.org 交易指南介绍了从签名、广播到纳入区块的过程。

交易等待的原因可能各不相同。费用上限可能不符合区块纳入条件，同一账户较早的一笔交易可能仍未解决，某个节点可能尚未收到交易，或者钱包显示了过时信息或特定服务商的信息。不同原因需要不同的检查方式。提高费用无法修正错误的网络选择；未检查第一笔交易就再次付款，则可能造成重复支付。

“待处理”也不同于“已确认”“已最终确定”或“失败”。交易回执生成之前，交易哈希可能已经可见；交易被纳入后，才会有回执。之后 Ethereum 区块还会经过共识状态的推进。钱包和区块浏览器对这些标签的用法可能不同，因此请检查交易哈希、区块、回执和当前链状态，不要只依赖一个简短状态标签。

普通 Ethereum 外部拥有账户（EOA）有一个用于排列交易的 nonce。Nonce 是计数器，不是费用、时间戳或唯一交易哈希。对于每个账户，链只接受使用该账户当前状态所预期的下一个 nonce 的交易。同一账户不能在规范链上执行两笔 nonce 相同的交易。Ethereum.org 账户文档将 nonce 描述为账户交易计数器和防重放机制。

假设某账户下一个未使用的 nonce 是 41。它下一笔有效交易使用 nonce 41；这笔交易被纳入并执行后，下一笔交易使用 nonce 42。Nonce 与发送账户相关，而非与目标地址相关。两个不同账户可以同时拥有编号为 41 的交易，因为它们各自有独立的序列。

可以使用高于账户当前链上 nonce 的值签署交易，但执行时不能跳过序列中的缺号。必须先消耗较早的缺失 nonce。若账户已经消耗某个 nonce，使用该 nonce 的交易就已过期，不能作为新交易执行。即使交易在不同时间广播或经由不同节点到达，这种排序也能让网络按顺序处理每个账户的交易。

Nonce 规则适用于 Ethereum 执行层上的普通 EOA 交易，并不能通用于所有钱包抽象、rollup 排序器或区块链。智能账户系统可以增加自己的操作和 nonce 规则，本文后面会再说明。

Ethereum 没有一个所有钱包、节点、区块浏览器和区块提议者都能以完全相同方式看到的同步等候室。每个执行客户端都会把自己收到、并依据自身限制和策略认为符合条件的交易保存在本地交易池中。一笔交易可能出现在某个节点的池中，却不在另一个节点的池中。Geth 的 txpool RPC 文档展示了该客户端本地的 pending 和 queued 组，并指出同一发送方和 nonce 可能对应多笔交易。

在 Geth 的术语中，pending 通常指从账户当前状态开始、可以按 nonce 顺序处理的交易；queued 则可能包括等待补上序列缺口的未来 nonce 交易。这些名称是客户端接口的分类，并非所有 Ethereum 软件都必须显示的共识层状态。钱包可能把全部未确认交易都称作“待处理”，而区块浏览器可能只显示其数据服务商观察到的交易。

例如，若一个节点知道 nonce 41 和 nonce 43 的交易，它就不能先执行 43、再执行 42。该节点可能会把 43 留在队列中，直到收到 42 或账户状态通过其他方式前进。另一个从未收到 43 的节点则完全不会显示它。因此，两个区块浏览器可能对交易究竟是待处理还是未找到给出不同结果，但任何一个屏幕都无法证明所有验证者看到了什么。

有些客户端也允许同一发送方和 nonce 对应多个未确认交易候选。它们是竞争同一个序列位置的备选项，而不是能够依次执行的两笔交易。交易池容量、交易保留时间和替换规则属于实现策略，可能随软件版本改变。例如，Geth 可配置的交易池选项包含客户端专用的价格上调阈值；不能把它当作 Ethereum 的通用费用规则。这些选项的适用范围见 Geth 命令行参考。

假设某账户下一个链上 nonce 是 41。你先广播 nonce 41 的交易 A，再广播 nonce 42 的交易 B。如果 A 仍未解决，B 就不能先执行。B 可能留在本地队列中，只在钱包里显示为待处理，或者因为某个区块浏览器没有收到它而完全不显示。关键是 nonce 的先后关系，而不是钱包创建或显示两笔交易的顺序。

如果 A 最终被纳入区块，账户 nonce 会前进到 42，之后 B 才可能符合条件，同时仍须满足自身的有效性、费用条件和交易池策略。如果 A 被另一笔同样使用 nonce 41 的有效交易替换，那么在替代交易被纳入时，它会占据同一个序列位置。如果账户的另一笔交易已经消耗 nonce 41，旧的 41 候选就会过期，无法再执行。

这就是为什么用更高 nonce 发送新交易不是解除卡住交易的通用办法：它只是在缺口后面再加一笔交易。如果 B 本来就是后续交易，取消 B 也无法解决 A。修改任何内容前，请先找到该账户最早的未解决 nonce，并核实它的状态。

缺口可能只是暂时的，也可能长期存在。较早的交易可能尚未到达你正在查询的节点、费用设置对当前条件缺乏吸引力或不足，或者已经从某个节点的交易池中移除。钱包也可能显示在另一台设备上创建的排队交易。单凭屏幕无法判断发生了哪种情况；请对照账户已确认的 nonce、交易哈希和多个可靠来源。

Nonce 顺序和费用资格是两个不同的限制。即使交易使用正确的下一个 nonce，如果费用参数不满足区块条件，它仍可能等待。Nonce 更高的交易不能仅靠提供更高的小费插队。提高 nonce 42 的费用不会让 nonce 41 消失。

对于标准 EIP-1559 交易，最高费用必须足以支付纳入该交易的区块基础费用，优先费用则可能影响区块提议者的选择。交易等待期间，基础费用和可用区块空间都可能变化。最高费用是上限；提高上限不能保证某个具体的确认时间。Ethereum Gas 费用指南介绍这些字段和有效费用的计算方式。

节点或钱包可能会实施额外的转发或替换规则。这些策略决定特定服务愿意接受或转发什么，并非全都属于共识规则。例如，Geth 提供可配置的价格上调阈值，用于替换自身交易池中的待处理交易。其他客户端、服务商、钱包或软件版本的行为可能不同。不要把记忆中的百分比或固定等待时长当作全网保证。

如果交易因为较低 nonce 尚未解决而等待，请先找出占用该 nonce 的交易。如果是最高费用不足以覆盖当前基础费用条件，请先理解费用字段再修改。Ethereum 费用指南适合了解费用计算；本文聚焦的是另外一个问题：交易排序。

钱包的“加速”功能通常会从同一账户创建一笔新交易，继续使用相同 nonce，但调整费用参数。账户只能执行一笔占用该 nonce 的交易，因此两个候选彼此冲突。如果相关交易池接受替换候选并将其纳入区块，它就可能占据该 nonce 的位置；原交易就不能再与它一起在规范链上执行。MetaMask 待处理交易指南将其自家的加速流程描述为使用相同 nonce 和更高费用重新提交。

替换交易可能保留原收款方和操作，只更改费用字段，但请查看签名界面，不要想当然。不同钱包实现可能显示其他字段或采用不同的功能名称。签署替换交易前，请确认发送账户、nonce、目标地址、金额和合约数据。如果替换交易改变了实际操作，它就不只是无害的费用调整。

替换交易不保证会在所有地方被接受，也不保证很快进入区块。原交易可能已经被纳入；节点可能依照自身策略拒绝替换交易；替换候选对区块提议者而言仍可能缺乏吸引力；服务也可能没有把它转发给你正在查看的节点。如果原交易已确认，再发送一笔使用已消耗 nonce 的交易无法撤销原交易，而且通常会因 nonce 过期而被拒绝。

这里的“替换”是指来自同一账户、使用相同 nonce 的竞争交易。不要把 Bitcoin 的 RBF 或 CPFP 操作搬到 Ethereum。Bitcoin 使用不同的交易模型，其提高费用的机制不是 Ethereum 账户的操作指南。

已签名的 Ethereum 交易一经广播，就没有能从所有节点撤回它的协议级撤销命令。有些钱包会在交易尚未确认时提供取消选项。该操作通常会尝试从同一账户发布另一笔使用相同 nonce 的交易；一种常见钱包模式是向发送方自己的地址发送一笔零金额交易。如果取消候选被接受并先于原交易进入区块，它就会消耗该 nonce，使原候选之后无法执行。具体构造方式和功能是否可用取决于钱包。

原交易和取消候选可能会竞速。如果原交易先进入区块，之后发送的取消操作就无法撤销其效果。如果两个候选都未被接受或纳入区块，nonce 可能仍未解决。点击钱包按钮或看到成功提示，不能证明取消候选赢了。请检查生成的交易哈希和规范链状态。MetaMask 的说明明确把取消尝试限定为仍在待处理的交易，并说明已确认交易无法取消。

签署取消交易前，请确认它使用的账户和 nonce 与要替换的交易相同，并检查钱包显示的所有字段。如果取消交易被纳入区块，可能还要支付一笔网络费用。取消候选也可能继续等待，或根据相关交易池策略无法替代原交易。钱包显示“已取消”并不代表协议层撤销；只有核实究竟是哪笔交易消耗了 nonce 后，才能判断结果。

如果交易已经执行了代币授权、合约调用或转账，取消后续交易无法撤销已经完成的状态变更。有些合约操作可能提供单独的后续方法，但是否可用及其后果取决于合约。不要仅仅因为界面称其为取消，就签署不熟悉的交易。

已纳入区块的交易有区块信息和回执。如果执行成功，预期的状态变更可能已经应用。如果 EVM 执行 revert，相关状态变更会回滚，但交易仍消耗账户 nonce，也可能仍需支付 Gas。请检查交易回执和执行状态，不要从钱包通知推断结果。Ethereum.org 交易指南和 Gas 指南介绍了纳入区块与执行结果之间的区别。

“已丢弃”或“未找到”通常只是某一个钱包、区块浏览器、RPC 服务商或本地交易池的报告。它本身不能证明协议已取消交易，也不能证明 nonce 已空出来。其他节点可能仍知道这笔交易；钱包可能重新广播已签名交易；后续区块也可能显示账户 nonce 已经前进。反过来，即使你查看的界面都没有显示旧交易，账户已确认的 nonce 也可能没有变化。

如果找不到交易哈希，请确认选择了生成该交易的同一条链和同一账户。将账户最新的链上 nonce 与交易 nonce 比较，并查看该发送方的近期交易。nonce too low 响应表示从当前端点的角度看，nonce 可能已经被消耗，而不是让你不断重复同一请求的理由。请确认是哪笔交易使用了它，以及相应区块是否仍在规范链上。

链稳定之前的短暂重组也可能影响已纳入区块的交易。钱包和区块浏览器可能会随其观察结果变化而更新标签。对于重要转账，请遵循接收服务的确认要求，并在适用时等待更强的共识最终性。“在一个区块中看到”与“在任何情况下都不可逆”并不是同一回事。

先确认链、发送账户和交易哈希均正确。在对应网络的可靠区块浏览器中查询该哈希。检查是否有回执、使用了哪个 nonce、执行是否成功，以及账户之后是否又发过交易。查询交易不需要公开或输入助记词；通过公共链查询，只需公开地址和交易哈希。

如果看不到哈希，请对比账户最新已确认的 nonce 和钱包显示的 nonce。开发者或节点运营者可以使用 latest 和 pending 区块标签查询 eth_getTransactionCount。Ethereum.org 的 JSON-RPC 参考将 latest 定义为最新区块状态，将 pending 定义为待处理状态。Pending 结果仍仅反映该 RPC 端点的视图；查询两个服务商可能得到不同数值。大多数用户无需运行命令，也能从钱包账户活动和可靠区块浏览器获得相同的初步线索。

随后从尚未消耗的最低 nonce 开始排查。如果原交易仍可见且钱包支持替换，请在签名之前仔细检查替换交易的具体字段和费用设置。如果看不到原交易，请询问钱包或 RPC 服务商如何处理重新广播与替换，不要直接假定交易已从网络消失。如果 nonce 已被消耗，先找出纳入区块的交易，再采取其他行动。避免不断提交更高 nonce 的新交易；那可能让队列更长，却无法填补最前面的缺口。

这些步骤适用于标准 Ethereum 外部拥有账户交易。账户抽象系统可以通过 bundler 提交 UserOperation，智能账户也可能使用多个 nonce 键和序列，而不是一个简单计数器。EIP-4337定义了这类操作的 nonce 结构，因此采用账户抽象的钱包可能不会像本文的 EOA 示例那样运作。关于目标网络、地址和转账状态，请继续查看加密货币转账检查清单。