转账提交后钱包里一直转圈，很多人下意识会再点一次确认，结果两笔交易同时排在那里，谁也不动。问题往往出在 Nonce 上。Nonce，是账户模型公链（如以太坊）给每个地址发出的交易按顺序编号的计数器，网络靠它确认这是这个地址的第几笔交易。同一账户的同一个 Nonce，最终只能有一笔交易被链上确认；未确认的交易能不能被后发的一笔顶替，取决于节点是否接受替换交易、新交易的手续费是否满足节点的替换规则。这也是”加速”和”取消”能顶替旧交易的原理。
核心要点
- Nonce 是账户级别的顺序计数器，不是随机数，标记的是这个地址发出的第几笔交易。
- 同一个 Nonce 最终只能有一笔交易被链上确认；能不能替换，看节点是否接受、新交易手续费是否达标，不是看发出时间的先后。
- 钱包里的”加速”和”取消”，本质都是用相同 Nonce、更高手续费重新提交一笔交易，让新交易顶掉旧的。
- 不是所有公链都有 Nonce：比特币靠 BIP 125 的”可替换”信号（RBF），现在不少节点默认也允许替换未标记的交易；Solana 的普通交易靠近期区块哈希，过期后需要重新构造才能再提交。
- 判断交易是不是真的卡住，要去区块浏览器核对账户已确认的 Nonce 和这笔交易的手续费设置，不能只盯着钱包里的”处理中”转圈。
适用范围：以太坊等账户模型公链的 Nonce 机制、比特币的 RBF 替换标记、Solana 的区块哈希过期机制，机制层面全球通用。
适用地区：判断交易状态和处理卡单的方法本身不分地区；但能不能持有、转账或交易虚拟资产，要按你所在地区的规则单独判断。
个人可参与度：本文说明的自查和加速、取消操作，只发生在你自己的钱包和公开区块浏览器上，不涉及资产买卖、开户或跨境资金转移；如果卡住的这笔交易本身牵涉交易所提现、跨境汇款等场景，能不能继续操作，要按你所在地区的规则判断。
主要风险点：①手动把 Nonce 调错或跳过某个编号，会让这笔和后面所有更大编号的交易一起卡住；②”加速”或”取消”时新交易的手续费加得不够高，等于又付了一次网络费却没解决问题；③比特币要不要接受替换，看钱包有没有提供替换入口、原交易有没有发出 opt-in 信号，也看节点和矿工当前采用的交易池策略——Bitcoin Core 28.0 起默认开启了 full-RBF（默认允许替换未标记信号的交易），29.0 起又移除了关闭该策略的选项，没标记也不代表一定不能被替换。
该核对的证据：区块浏览器上这个地址当前的 Nonce 值、这笔交易排队中的具体状态、当前网络要求的手续费水平，而不是钱包页面上一句”交易处理中”。
资料截至：2026-09-22；协议参数可能随版本升级调整，请以官方文档最新版本为准。
目录
Nonce 到底是什么？
Nonce 的字面意思是”只用一次的数字”，但在以太坊这类账户模型公链里，它的实际作用是给一个地址发出的交易按顺序编号，从 0 开始，往后依次是 1、2、3……
账户的交易计数器，不是随机数
Ethereum 官方文档在解释账户机制时说明，Nonce 是一个计数器，记录的是某个外部账户已经发出的交易数量，或者某个合约账户已经创建的合约数量。文档同时强调，一个给定的 Nonce 对每个账户只能对应一笔能被执行的交易，这正是防范重放攻击的关键——已经签名并广播过的交易，不能被人反复拿出来再执行一次。
区块浏览器和钱包显示的 Nonce，其实有两种统计方式：一种是账户在链上已确认状态里的 Nonce，标记的是下一笔待发交易该用的编号；另一种是把待处理（pending）交易也算进去的 Nonce，两者不总是同一个数字。举例来说，一个地址链上已确认的 Nonce 为 100，意味着编号 0 到 99 的交易已经被计入状态，下一笔交易通常会用 Nonce 100，也就是从 0 开始数的第 101 个编号。
查一个地址目前发到了第几笔交易、当前还有没有排队中的编号，直接去区块链浏览器核对即可，但要留意浏览器展示的是”已确认”还是”含 pending”的数字。
为什么交易必须按编号顺序生效
以太坊官方文档把 Nonce 描述为”按顺序递增的计数器”。网络处理一个地址的交易时认的是编号顺序：Nonce 为 5 的交易没有被打包，Nonce 为 6 的交易就算已经准备好，也要排在后面等。网络不会跳过中间的编号直接执行后面那笔。这也是为什么一笔小额转账没确认，后面所有想发的交易都会跟着堆在那里——它们共用同一套编号队列，卡住的是队伍最前面那一个，不是某一笔单独出了问题。
交易卡住是怎么发生的？
交易迟迟不动，通常不是”网络坏了”，而是这笔交易此刻还没有满足被打包的条件。
两种真正的卡住原因
先看清是不是这两个原因造成的，再决定该等还是该加速。
| 现象 | 常见原因 | 说明 |
|---|---|---|
| 提交后长时间显示”处理中” | 手续费低于当前网络要求的水平 | 验证者优先打包出价更高的交易，出价低的会一直排在后面 |
| 后面发的交易也一起卡住 | 前一个 Nonce 的交易还没确认 | 同一账户的交易按 Nonce 顺序处理，前面没通过，后面的也要等 |
两种容易被误判成卡住的状态
这两种情况看着也像卡住，但原因不一样，处理方式也不同。
| 现象 | 常见原因 | 说明 |
|---|---|---|
| 区块浏览器查不到这笔交易 | 交易还没被节点广播开、浏览器索引有延迟，或者已经因为长期不满足条件被节点清理 | 需要换个浏览器或稍等几分钟，用交易哈希重新核对，而不是只看钱包里的记录 |
| 钱包显示”失败”但仍然扣了费用 | 交易被打包执行了，但执行结果回滚 | 属于另一类问题，和卡在待处理不是一回事 |
交易卡住自查清单：按顺序核对，再决定怎么办
遇到卡单，按顺序把下面几件事核对一遍，能大致判断出该等、该加速还是该取消，不用凭感觉重复点确认。
- 第一步，确认查的对不对：先核对区块浏览器选的是不是交易发出时用的那条网络（主网还是测试网、哪一条 Layer2），再核对交易哈希和发送地址有没有抄错，排除因为查错地方而误判的情况。
- 第二步，查这笔交易的状态：把交易哈希输入区块链浏览器，看它是”待处理（pending）“、已经被打包，还是查不到。查不到不能直接当成”从一开始就没被网络接受”——也可能是节点还没把它传播开、浏览器索引有延迟，或者它已经因为长期不满足条件被节点从本地交易池清理。稳妥的做法是换一个浏览器、或者稍等几分钟再查一次，仍然查不到才考虑重发。
- 第三步，先分清账户 Nonce 是”已确认”还是”含 pending”：区块浏览器和钱包给出的账户 Nonce 有两种统计方式，一种只算链上已确认的交易，一种把待处理交易也算进去，两者可能不是同一个数字；不同 RPC 节点对”最新状态”（latest）和”待处理状态”（pending）的判断标准也可能不一致。
- 第四步，用已确认的 Nonce 判断编号是否已被消费：只有已确认的账户 Nonce 大于这笔交易的 Nonce，才能确定这个编号已经被链上消费；只是含 pending 的 Nonce 追上了，不能当成已被替换的证据。
- 第五步，确认到底是哪一笔交易执行了：确定这个编号已被消费后，还要去这个地址的交易记录里，用交易哈希核对实际上链的是不是你后来发的那笔（比如加速或取消的那一笔），不要想当然认为一定是自己的替换交易顶替了旧交易。
- 第六步，查手续费是否跟得上网络要求：如果这笔交易确实还在排队，看它的手续费是不是明显低于同一时间其他交易的水平。价格没跟上，才需要用同一个 Nonce、更高手续费重新提交；手续费本身不低，只是网络拥堵，可以继续等待。
几步查完，能不能操作也就清楚了：网络、哈希或地址核对不上，先改正再查；改正后仍然查不到，才考虑重发一笔全新交易；已确认 Nonce 追上、且核对过确实是自己的替换交易执行了，就不用再管；Nonce 还在排队且手续费偏低，才需要用同一个 Nonce 重新出价。
加速和取消，靠的是同一个机制
钱包里常见的”加速”（speed up）和”取消”（cancel）按钮，背后不是两套逻辑，而是同一个原理的两种用法。
加速：同一个 Nonce，出更高的价格
MetaMask 官方帮助文档说明，“加速”会用和原交易相同的 Nonce，重新提交一笔手续费更高的交易。因为复用了同一个 Nonce，不会因此多扣一次原交易的费用——最终只有出价更高、被验证者接受并打包的那一笔会真正执行并扣费。文档同时给出参考：新交易的优先费用建议比原交易至少提高一成，手续费上限则建议提高三成左右；具体加价门槛不同钱包可能各有各的规则。
取消：同一个 Nonce，转给自己零值
“取消”用的是同样的原理，只是把交易内容换成转账金额为零、收款地址填自己、同样用原来的 Nonce、同样出更高手续费。这个 Nonce 最终只有一笔交易会被打包执行，取消交易一旦被打包，原来那笔就不会再生效。
常见误区：不能靠发一笔新 Nonce 的交易来取消旧的
不少人遇到卡单，下意识会再发一笔转账，但如果这笔新交易用的是下一个 Nonce，它只会排在原来那笔后面等，并不会取消或跳过前面卡住的交易——网络仍然要求编号靠前的交易先满足条件。真正能顶替某笔交易的，只有用相同 Nonce 出价更高的那一笔。
换一条链，同样的问题怎么处理？
不是所有公链都用 Nonce 这套机制，换到比特币和 Solana，处理卡单和替换的逻辑并不一样。
比特币：没有账户 Nonce，靠一个”可替换”标记
比特币不是账户模型，也没有 Nonce 这个概念。BIP 125 定义了”opt-in 全量手续费替换”（Replace-By-Fee，RBF）信号机制：发送方在最初广播交易时，把某个输入的序列号（sequence）设置成低于 0xFFFFFFFE 的值，相当于提前声明”这笔交易允许被更高手续费的版本替换”。这套信号最初的设计前提是：没做声明的交易，节点不会接受替换。
但 Bitcoin Core 从 2024 年 10 月发布的 28.0 版本起，把 mempoolfullrbf 的默认值改成了开启，也就是默认允许替换未标记 RBF 信号的交易；2025 年 4 月发布的 29.0 版本又移除了关闭这个选项的开关，full-RBF 成了标准行为。
也就是说，一笔交易能不能被替换，最终看钱包有没有提供替换入口、原交易是否发了 opt-in 信号，以及连接的节点和矿工当前采用的交易池策略——没有标记 RBF，也不代表在所有节点上都一定不能被替换。
Solana：没有 Nonce，靠区块哈希自动过期
Solana 的普通交易不用 Nonce，而是在交易里带上一个”近期区块哈希”（recent blockhash）。官方开发文档说明，节点只认最近 151 个 blockhash 为有效，由于每个 slot 通常约 400 毫秒，这个窗口大致相当于 60~90 秒，具体判断以交易自带的 lastValidBlockHeight 为准。
过了这个窗口，这笔交易就不会再被处理；用户不需要手动”取消”，但要不要重新构造、签名并提交一笔新交易，取决于钱包或应用的实现，不是协议自动完成的。
官方开发文档还介绍了另一种可选机制——耐用 Nonce（durable nonce）：用一个链上专门的 Nonce 账户替代区块哈希，这个值不会随时间过期，只有在被”推进”（advance）之后才会更新，这套机制通常用在离线签名、需要更长有效期的场景，普通钱包转账默认走的还是会过期的区块哈希方式。
三条链的处理逻辑对照
同样是”这笔交易卡住了该怎么办”，三条链给出的答案完全不同。
| 链 | 有没有 Nonce 概念 | 靠什么处理卡单/重复提交 | 交易多久算失效 | 普通用户能不能自己”取消” |
|---|---|---|---|---|
| 以太坊（账户模型） | 有，按地址顺序递增 | 用同一 Nonce、更高手续费重新提交（加速/取消） | 协议没有统一的固定到期时间；单个节点可能按本地策略清理长期不满足条件的交易，之后可能需要重新广播 | 能，钱包通常提供加速/取消入口 |
| 比特币（UTXO 模型） | 没有 | 钱包是否提供替换入口、原交易是否发出 opt-in 信号，加上节点/矿工当前采用的交易池策略（新版 Bitcoin Core 默认允许替换未标记交易） | 协议没有统一的固定到期时间，但节点可按本地策略清理，之后可能需要重新广播 | 能不能替换看钱包是否提供入口、连接的节点是否接受替换；标记 RBF 更容易被接受，但节点当前的策略同样关键 |
| Solana（账户模型，但不用 Nonce） | 普通交易没有，只有可选的耐用 Nonce 机制 | 靠区块哈希本身的时效性，过期即失效 | 最近 151 个 blockhash 内有效，通常约 60~90 秒，以 lastValidBlockHeight 为准 | 不需要主动取消；过期后原交易不会再被处理，是否重新构造、签名并提交取决于钱包或应用 |
换链之前先确认自己在用哪套逻辑，比记住某一条链的操作步骤更管用——以太坊上的”加速""取消”概念，搬到比特币或 Solana 上并不成立。
回到具体怎么办：不管在哪条链，交易卡在待处理状态，原因通常落在三层里的某一层——网络本身在拥堵、这笔交易的手续费没跟上，或者前面还有一笔未确认的交易挡住了队列（以太坊按 Nonce 顺序排队，比特币和 Solana 按各自的机制处理，见上表）。分清楚是哪一层，再决定继续等，还是出更高的价重新提交，比反复点”确认”更有用。不确定手续费该出到多少时，回到区块浏览器和钱包给出的网络费估算，比凭感觉加价更可靠。
常见问题
Q： Nonce 是不是随机生成的数字？
答： 不是。以太坊官方文档把它定义为账户级别的顺序计数器，标记的是这个地址已经发出的交易数量，从 0 开始按顺序递增。它和”挖矿难题”里用来碰撞哈希值的那个随机数不是一回事——两者虽然都叫 Nonce，含义完全不同。
Q： 交易卡多久才应该加速？
答： 没有统一的固定时间，要看当时的网络拥堵程度和你对这笔交易的紧迫性。可以先去区块浏览器核对当前网络要求的手续费水平，和自己这笔交易的出价差多少；如果差距明显，等待未必能等到打包，更值得直接用更高手续费重新提交。
Q： 取消交易失败会怎样？
答： 取消本质上也是一笔交易，同样需要被网络接受才会生效。如果取消交易出的手续费仍然不够高，它可能和原交易一样继续排队，原交易也还有被打包的可能——取消不是”撤回”，而是”用更高价格抢在前面”，价格给得不够，抢不过原交易。
Q： 比特币的交易能自己撤销吗？
答： 按 BIP 125 的规则，输入的序列号被设置为低于 0xFFFFFFFE，这笔交易才算主动发出了”允许替换”的信号；但这只是信号机制，不能单独决定最终结果。Bitcoin Core 从 2024 年 10 月发布的 28.0 版本起，默认允许替换未标记信号的交易，2025 年 4 月发布的 29.0 版本又移除了关闭这项设置的开关，full-RBF 成了标准行为。也就是说，普通用户能不能替换一笔交易，还要看自己的钱包有没有提供替换入口，以及广播交易的节点当前采用的交易池策略。
Q： Solana 交易一直不确认，需要手动处理吗？
答： 通常不需要你手动操作。Solana 的普通交易带着一个近期区块哈希，官方开发文档说明只有最近 151 个 blockhash 内的哈希才算有效，大致相当于 60~90 秒，具体以交易自带的 lastValidBlockHeight 为准。过期后这笔交易不会再被处理，是否重新构造、签名并提交一笔新交易，要看具体钱包或应用的实现，不是协议保证的行为。
Q： 手动修改 Nonce 有风险吗？
答： 有。如果手动把 Nonce 设置得比账户当前编号更大，跳过了中间的编号，这笔交易会一直卡在那里等前面的编号补齐，后面继续发出的交易也会跟着排队。如果设置得比当前编号更小，则可能因为这个编号已经被使用过而直接失败。多数人不需要手动改 Nonce，钱包默认的自动编号已经能处理绝大多数场景。
Q： 不同钱包的”加速”效果都一样吗？
答： 原理一样，但具体加价幅度和是否提供这个入口，取决于各家钱包自己的实现。有的钱包会给出建议的加价门槛，有的需要自己手动设置手续费；用哪个钱包操作，请以该钱包官方帮助文档给出的具体说明为准。
参考资料
- Ethereum.org：Ethereum accounts
- Ethereum.org：Transactions
- Ethereum.org：Block explorers
- Bitcoin.org：BIP 125 — Opt-in Full Replace-by-Fee Signaling
- Bitcoin Core：28.0 Release Notes（mempoolfullrbf 默认开启）
- Bitcoin Core：29.0 Release Notes（移除 mempoolfullrbf 选项，full-RBF 成为标准行为）
- Solana：Transaction Confirmation & Expiration
- MetaMask Help Center：How to speed up or cancel a pending transaction
版本 1.0 · 更新于 2026-09 · 资料截至 2026-09-22。本文解释 Nonce、交易替换与过期机制，不构成投资、交易或法律建议；能否持有、转账或交易虚拟资产，请以你所在地区的官方规则为准。