轉帳排錯指南 / 問題排查

Ethereum 交易卡住或 Reverted 時該看哪些欄位?

用 nonce、Gas、區塊位置與 receipt status 分辨卡住和執行失敗。

快速判斷

先看結論

pending 表示交易尚未形成成功收據,reverted 則表示交易已入塊但執行失敗;前者要看 nonce 與費率,後者要看 receipt status 和合約錯誤,已用 Gas 通常不退。

Receipt 狀態:鏈上轉帳交易排錯主題圖
本篇主題圖 · 最後核實 2026-08-04

先區分「還沒執行」和「執行後回滾」

Ethereum 交易 pending,通常表示尚未有被區塊收錄的最終 receipt;reverted 則表示已經進入區塊、EVM也執行過,但狀態變更因錯誤而回滾。兩者處理方向完全不同。

pending 時重點是廣播、nonce與費率。reverted 時重點是合約呼叫、輸入資料、可用 Gas與合約條件。把 reverted 當成「多等一下」不會變成功,把 pending 當成合約錯誤也可能白費時間。

Pending:沿 nonce 佇列往前查

每個外部帳戶的交易按 nonce 排序。較小 nonce 的交易未被處理,後續 nonce 即使費率更高也可能無法先執行。打開帳戶的 pending 交易列表,查看是否有更早交易卡住。

再比較交易的費率參數與目前區塊條件。錢包若支援 speed up,通常會用相同 nonce 建立費率更高的替代交易;cancel 也常是用相同 nonce 向自己發送另一筆交易。它們不是修改原交易,而是競爭哪一筆被先納入。

操作前先確認:

  • 錢包是否真的連接 Ethereum 主網;
  • 原交易是否仍被節點看見;
  • 替代功能是否使用相同 nonce;
  • 新交易內容與最大費用是否可接受;
  • 是否有更早 nonce 必須先處理。

不要同時在多個錢包隨意重設 nonce。你可能建立一串互相競爭的交易,讓判讀更困難。

Reverted:receipt 已經給出結論

eth_getTransactionReceipt 在交易尚未入塊時可能沒有結果;入塊後 receipt 包含區塊、實際 Gas使用與 status。status失敗表示狀態回滾,但已完成的計算仍消耗 Gas。

常見原因包括合約條件不滿足、allowance不足、滑點或期限失效、呼叫錯誤函式、合約暫停,以及 Gas limit不足。只把費率提高不會修復業務條件;應先從應用錯誤、交易 input與合約事件找原因。

訊號 Pending Reverted
是否有區塊 receipt 通常沒有
主要變數 nonce、廣播、費率 合約邏輯、input、Gas limit
等待是否可能改變 可能被納入或替換 不會自行變成功
是否可能已花 Gas 尚未最終扣除 通常已消耗實際 Gas

Token 沒轉出但 ETH 少了

這是 reverted 最容易造成的誤會。代幣狀態已回滾,所以 ERC20餘額仍在;驗證者執行交易所需的 Gas卻已使用,所以 ETH減少。查看 receipt 的 gasUsed 與有效費率即可核對,不要把它誤判成平台偷扣代幣。

若交易 success但代幣餘額未如預期,則要看是否呼叫了錯合約、transfer事件中的地址與數量,或介面顯示的是不同鏈、不同代幣合約。

向支援提供可用資料

對錢包或應用支援提供 transaction hash、chain、時間、應用操作與公開 receipt。若問題可重現,可記錄不含敏感資料的錯誤訊息。seed、私鑰、密碼、API secret 或一次性驗證碼一律不得交出。

對任何「支付一筆 ETH即可把 reverted 改成 success」的說法保持警惕。已確認的 receipt 不會被事後改寫;你只能在理解錯誤後建立一筆新的交易。

Pending 之前先確認交易是否真的被節點接受

錢包顯示「已提交」不一定表示所有節點都能查到 hash。先在可信 Ethereum 資料來源查詢交易,再核對發送地址的 latest 與 pending nonce。若 hash 查不到,但錢包已建立另一個相同 nonce 的交易,原交易可能只停留在特定 RPC、被移除或已遭替換。

記錄原 hash、nonce、費用參數、接收地址和送出時間。不要立即在另一個錢包用隨機 nonce 重送;多個介面各自管理 pending 狀態,容易建立衝突候選。

Pending 很久,應該 Speed up 還是 Cancel?

Speed up 通常以相同 nonce、相同意圖和更有競爭力的費用建立替代交易;Cancel 常以相同 nonce 向自己發送零值交易競爭。兩者的前提都是原交易尚未確認,且替代交易符合節點規則。按下按鈕不是撤銷保證,最後被打包的可能仍是原交易。

目標 應核對 主要風險
加速原付款 相同 nonce、收款與數量不變 錢包重新產生了不同資料
取消付款 相同 nonce、自轉內容、費用更高 原交易先被確認
解開 nonce 佇列 最小 pending nonce 跳號後續仍卡住
只等待 地址正確、時間不急、費率仍有機會 收款方把未確認當成結算

每次操作都保存新 hash。區塊瀏覽器可能將舊交易標成 replaced,但應以最終區塊中的 nonce 與 receipt 為準。

Reverted 為什麼仍會扣 ETH?

驗證者已執行交易並消耗計算與區塊空間,即使合約最後回滾狀態,已使用的 Gas 通常仍需支付。Receipt 的 status、gasUsed 與 effectiveGasPrice 能協助計算實際費用。Gas limit 是允許消耗上限,不是一定扣除的數字。

Revert 原因可能來自滑點、截止時間、餘額/授權不足、合約暫停、錯誤參數或應用自己的檢查。提高 Gas limit 只能避免因資源上限不足而中止,不能繞過業務條件。先用可信工具模擬並閱讀合約錯誤,再決定是否重試。

代幣授權成功、兌換失敗時發生什麼?

Approve 和 Swap 常是兩筆獨立交易。授權 success 只表示合約可以在指定額度內動用代幣,不表示後續兌換已完成。Swap reverted 時,授權可能仍存在。若不再使用該合約,應評估透過可信權限管理工具降低或撤銷 allowance。

不要因介面顯示「交易失敗」就忽略成功的授權,也不要把撤銷權限連結交給搜尋結果中的陌生網站。先從官方錢包或可信來源查看 spender、token 與額度。

Pending 案件先畫出 nonce 佇列

把同一發送地址最近的交易按 nonce 排序,標出已確認、pending、replaced 與本地草稿。Ethereum 會依 nonce 順序處理同一帳戶的交易;較早的低費率交易沒有完成時,後面的交易即使出價較高,也可能無法越過。只盯著最後一筆 hash 會把佇列問題誤認成單筆網路擁塞。

每次 speed up 或 cancel 都要保存原 hash、新 hash、相同 nonce、接收地址、value、data 與費用參數。所謂 cancel 通常也是一筆競爭相同 nonce 的新交易,不是從礦工記憶池刪除舊資料。若舊交易先被打包,取消交易可能失效;因此操作前必須再次確認鏈上狀態。

費用不足與節點未見交易如何區分?

多個同步的可信瀏覽器都能找到 hash、但長時間沒有 receipt,較像已廣播的 pending;只有錢包本地紀錄、公開節點查不到,則要檢查 RPC 回覆、廣播錯誤與交易是否被節點接受。不要因查不到就立刻建立同內容、不同 nonce 的第二筆付款,否則原交易稍後出現時可能造成雙付。

費用判斷要看 base fee、priority fee、max fee 與交易建立時間,不用固定的 gwei 數字。EIP-1559 參數只是上限與小費設定,實際支付仍受區塊條件影響。錢包估算失常時,先換可信資料源,不要聽從私訊者給的「保證打包」參數。

Reverted receipt 可以證明到哪一步?

Receipt 的 status 表示 EVM 執行是否成功;reverted 代表狀態變更回滾,但交易本身已被區塊包含,Gas 仍支付給執行與驗證。接著查看 to、input、logs、gas used 與可得的 revert reason,分辨是餘額、allowance、slippage、deadline、合約暫停或應用前置條件。介面顯示的泛用錯誤不能取代 receipt。

不要把「代幣還在」理解成「什麼都沒發生」。前一筆 approval 可能成功、nonce 已消耗、ETH 餘額已扣,DApp 內部訂單也可能留下失敗記錄。重試前逐項核對,特別是 spender allowance 與新交易會否再次扣款。

合約模擬有用,但不能承諾實際成功

模擬可在當前狀態下重現部分錯誤,協助讀取 revert reason;但區塊狀態、價格、nonce、流動性和合約條件在真正打包前可能改變。模擬成功不是收益或成交保證,模擬失敗也不應用提高 Gas limit 掩蓋。把模擬輸出與實際交易參數一起保存,才能向 DApp 支援描述差異。

遇到未知 calldata 時,不要把資料貼到會要求連接錢包的解碼網站。可先用公開 ABI、可信瀏覽器或離線工具閱讀函式與參數;查詢不需要簽名。

平台提領 pending 時,誰有能力替換交易?

若交易由交易平台熱錢包建立,輸入、nonce 與簽名權在平台。收款人無法用自己的錢包 speed up,向礦工支付陌生「加速費」也不會取得平台帳戶的替換權。應提供提款單號、TxID、網路、目的地址與目前確認狀態,詢問平台是否正在替換或重新廣播。

平台若給出新 hash,要核對是否使用相同 nonce、輸出是否仍包含你的地址與金額,再把兩者關係告知收款方。不要只刪除舊 hash;完整記錄才能解釋為何原交易後來顯示 dropped 或 replaced。

事件結束後如何做安全收尾?

記錄最終被確認的 hash、區塊、receipt、實際費用、失敗交易與任何仍存在的 allowance。若曾連接陌生 DApp,檢查近期授權與簽名;發現不需要的高額 allowance 時,使用可信錢包或經核實的權限工具處理。撤銷本身也是鏈上交易,也需正確 Gas 與合約核對。

最後把原因寫成可驗證句子,例如「nonce 42 的替代交易先被確認」或「swap 因 deadline 條件 reverted,approval 仍存在」。這比「Ethereum 卡住」更能預防下一次重複操作。

L2 或跨鏈介面顯示 Pending 時先確認哪一層?

在 rollup、交易所提領或橋接流程中,介面可能把來源鏈交易、批次提交、挑戰期、訊息 relay 與目的鏈執行全部概括為 pending。先找到實際 Ethereum 或 L2 TxID,確認 transaction 位於哪條鏈,再查看協議官方狀態。不要拿 L2 hash 直接到 Ethereum 主網搜尋,也不要把橋接訂單號當鏈上 hash。

來源鏈 success 只證明第一段完成。後續等待可能由協議規則造成,盲目在 Ethereum 主網建立相同付款不會縮短流程。若協議提供 claim,核對官方合約、目的鏈與 calldata,避免從私訊連結操作。

多簽帳戶的 nonce 與一般 EOA 有何不同?

多簽錢包常有自己的提案序號與簽署門檻,真正送到 Ethereum 後才有 EOA 層交易 nonce。提案停住可能只是簽名不足,不是 mempool 低費率;鏈上執行 reverted 也可能因門檻、模組或內部呼叫條件。先分清提案 ID、錢包內部 nonce 與外層 TxID。

任何新增簽署人或模組的交易都可能改變控制權。不要因急著處理 pending 而批准看不懂的 owner 變更,並在硬體裝置核對最終呼叫。

付款方與收款方如何避免對同一狀態各說各話?

付款方提供 TxID、chain、nonce、目前 receipt、接收地址與替代 hash;收款方提供接受何種完成標準與是否已在自己的地址或平台帳戶看到資產。雙方使用同一筆公開交易作基礎,不以錢包推播或平台內部 Completed 單獨定案。

若交易 reverted,付款方不應以已付 Gas 要求收款方交付;若交易 pending,收款方也不應宣稱資產已不可逆到帳。把技術狀態與商業處理條件事先寫清楚,可減少重複付款與退款爭議。

交易長時間 Pending 時怎樣設定升級節點?

先記錄建立時間、當時費用參數、最早未確認 nonce、目前 base fee 與收款期限。不是每隔固定分鐘就重送,而是在條件改變時重新評估:原交易從公開 mempool 消失、費率明顯失去競爭力、平台給出替代 hash,或業務期限逼近。每次評估都再次查原 hash,防止剛被確認卻建立衝突付款。

自託管錢包可以依功能選擇安全替換;平台熱錢包只能由平台操作。向收款方說明目前可驗證狀態和下一次檢查條件,比保證某個分鐘數更可靠。

讀取 Revert 原因時怎樣避免被前端誤導?

以 receipt、trace、公開 ABI 與 simulation 為證據,對照實際 block 狀態。前端可能只顯示通用「execution failed」,甚至沿用舊錯誤;第三方解碼也可能因 ABI 不完整而猜錯函式。若找不到原因,保留 calldata、合約、區塊與錯誤原文,交給 DApp 官方支援,而不是在陌生網站再次簽名。

原因找到後仍要判斷是否可重試。餘額或 allowance 可補足,deadline 或價格條件可重建;合約暫停、權限限制或惡意合約則不應靠提高 Gas 解決。

最終帳務如何處理失敗交易與成功替代交易?

失敗或被替換的交易仍可能有 Gas 成本,成功版本則決定真正的資產移動。對帳時列出所有相關 hash、nonce、status、費用與輸出,只把最終有效 Transfer 計為付款。若 cancel 成功,記錄它是一筆向自己發送的競爭交易,而不是收款人退款。

平台批次交易還要把內部提款單與新舊 hash 關聯。完整鏈路能防止客服或會計把舊 hash 的 failed 狀態誤認為整筆提款從未完成。

真實公開頁面

畫面證據

Ethereum Execution APIs 的 eth_getTransactionReceipt 官方方法頁截圖
真實公開頁面:Ethereum Execution APIs 的交易收據方法,用來核對區塊位置與執行 status。查看原始來源 ↗

核對依據

來源與核對邊界

下列公開頁面支持本文的協議、欄位或風險說明。平台政策與即時費用仍應在操作當下重新核對。
  1. ethereum.orgTransactions最後檢查: 2026-08-09 · 開啟外部來源 ↗
  2. ethereum.orgEthereum gas and fees: technical overview最後檢查: 2026-08-04 · 開啟外部來源 ↗
  3. Ethereum Execution APIseth_getTransactionReceipt最後檢查: 2026-08-04 · 開啟外部來源 ↗
  4. ethereum.orgEthereum accounts最後檢查: 2026-08-09 · 開啟外部來源 ↗
  5. ethereum.orgBlocks最後檢查: 2026-08-06 · 開啟外部來源 ↗
  6. Ethereum Improvement ProposalsERC-55: Mixed-case checksum address encoding最後檢查: 2026-08-04 · 開啟外部來源 ↗