帳戶與安全
區塊確認數是什麼？轉帳等待確認的排查順序
區分未入塊、確認不足與服務未入帳，學會 Bitcoin 確認數計算及真實畫面判讀，判斷何時等待、查詢或停止重付。
區塊確認數描述交易被納入鏈上歷史的深度。轉帳一直「等待確認」時，先分清它是尚未入塊、已入塊但未達收款門檻，還是鏈上完成後服務尚未入帳；三種情況的處理對象不同，重送付款通常不能解決這個判斷問題。
適用讀者與前置條件
本文適合已有一筆待查轉帳、想知道應該等候還是求助的讀者。先準備網路、完整 TxID、收款地址、資產與數量，以及收款服務目前要求的確認條件。沒有 TxID 時，先確認付款申請是否已實際廣播。
如果還沒送出，不必先猜要等多久；應先完成轉帳前的網路、地址及小額測試核對。下文以 Bitcoin 主網說明確認計數，其他網路的最終性規則不能直接套用同一數字。
確認數、執行成功、最終性與入帳
| 概念 | 它回答的問題 | 它不能保證什麼 |
|---|---|---|
| 已入塊／確認深度 | 交易是否被區塊收錄，後面又累積了多少區塊？ | 不能保證填對地址或資產 |
| 合約執行結果 | 呼叫是否成功，或發生回退？ | 成功不等於完成你的預期收款 |
| 最終性 | 共識規則如何使已接受的歷史難以逆轉？ | 不是跨網路通用的倒數計時 |
| 服務入帳 | 收款服務是否已把款項記入可用餘額？ | 不只由瀏覽器上的綠色狀態決定 |
Bitcoin 中，交易所在區塊本身算第 1 次確認。對仍在目前有效主鏈上的交易，若交易區塊高度為 h、目前鏈尖高度為 H，確認數就是 H − h + 1。尚未入塊不能用這個公式硬算；若發生衝突或重組，必須先確認交易是否仍在有效鏈上。Bitcoin 區塊鏈指南與 Bitcoin Core 確認及衝突欄位提供計數與狀態的依據。
Ethereum 權益證明另有透過驗證者投票、檢查點建立的最終性，不能把「多等幾個區塊」直接等同其 finalized 狀態。詳細規則見 Ethereum 最終性文件。本文不提供適用所有網路、所有金額的安全確認數。
真實畫面：預估中的區塊不是已產生的區塊
圖為本次擷取的Bitcoin 網路概覽。左側綠色區塊與分鐘數是待確認交易的預估；右側帶高度的紫色區塊代表已產生的區塊。這是畫面當時的觀測，費率、佇列和時間都會變動，不是本站承諾的確認時間。
用瀏覽器做一次只讀核對
- 在可信的同網路瀏覽器貼上完整 TxID，確認交易字串與付款紀錄一致。
- 查看是否已有交易區塊及確認數。只有全網概覽，不能判斷自己的交易已被收錄；必須回到單筆交易頁。
- 若有區塊，記下交易高度；再查同一主網目前鏈尖高度，用上述公式核對。頁面先後更新可能造成短暫差一個區塊，應刷新後再比較。
- 核對收款地址、資產、數量和合約執行結果（如適用），然後比較收款端的當期要求。已達確認數並不能修正錯填的資料。
- 記下查詢時間、確認數及下一步。下一次查詢比較的是同一筆交易與同一網路，不要只保存無日期的截圖。
這項練習只需要公開識別資料；若某頁要求連接錢包或付款才可查確認，先停止。
為什麼會等？按所在階段排查
還沒有 TxID，或只有服務內部編號
可能仍在付款端處理、簽名或廣播之前。向付款端確認實際進度與是否產生鏈上識別碼。不能把「已提出轉出申請」的時間全部當成區塊鏈確認耗時。
已廣播，但尚未入塊
Bitcoin 的區塊空間有限，交易費率、交易大小和未確認相依交易會影響收錄。只看支付了多少總費用不足以比較優先順序。網路繁忙時，佇列預測也可能反覆改變；Bitcoin 付款處理文件說明未確認交易和費用處理的限制。
Ethereum 類帳戶模型還要留意先前序號的交易：nonce 是帳戶交易的遞增序號，後續交易可能受前序未處理交易影響。這不是 Bitcoin 確認數公式的一部分，應依該網路交易文件分開判讀。
已入塊，收款端仍顯示等待
先確認當期門檻是否達到。如果未達，持續追蹤；如果已達，核對資產、網路、最低入帳額、必要附加識別與維護公告，再向收款端查詢內部入帳。不要要求付款人因為服務延遲而再付一次。
等候、加速或求助：何時採取哪一種行動
| 可確認的事實 | 下一步 | 停止條件 |
|---|---|---|
| 尚未廣播 | 查付款端處理狀態 | 不自行假定鏈上卡住 |
| 未確認且資料正確 | 等待並追蹤費率與相依交易 | 不重送一筆獨立付款 |
| 原錢包明確支援調整待確認交易 | 先讀官方說明、成本和適用條件 | 不理解簽名或替代結果就不操作 |
| 已達收款要求但未入帳 | 向收款端提交證據 | 不為「解鎖入帳」另付資金 |
| 地址／資產錯誤、交易衝突或執行失敗 | 保存證據，辨認錯誤類型 | 不等待更多確認來修正錯誤 |
「加速」不是撤銷已確認交易。Bitcoin 的費用替代與子交易付費、其他網路的序號替代，適用條件並不相同；本站不要求你手動建立救援交易。若款項由託管服務發送，通常也不是你控制原始簽名。可先讀錢包控制權與託管責任比較判斷應聯絡哪一方。
核對紀錄：讓等待變成可查的時間線
每次記錄以下六項：查詢時間（含時區）、網路與 TxID、是否入塊、確認數／最終性、收款端要求、下一步。若出現替代 TxID，把新舊關係一起記下；不要將舊交易找不到誤判為新交易不存在。
完成的標準是：正確款項已達接收條件，並在收款端核實結果；若仍有問題，至少已定位付款端、鏈上或收款端哪一段缺乏證據。向支援提供可複製的 TxID 與查詢時間，不要只傳畫面。
常見錯誤與風險邊界
- 把平均出塊時間當作單筆交易承諾：區塊產生有波動，低費率也可能延後首次收錄。
- 把首頁的預估分鐘數當作自己的排隊號碼：必須回單筆交易頁核對，預測不能保證位置。
- 以為多等幾次確認能修復合約回退、錯誤地址或附加識別缺失：這些是不同問題。
- 為求快速入帳重複提交付款，或把助記詞交給所謂加速人員：前者可能重付，後者可能失去控制權。
確認增加只強化對相應鏈上歷史的信心，不代表收款對象可信，也不消除資產價格或服務託管風險。確認時間及不可逆性限制可參閱 Bitcoin 使用前須知。
FAQ
確認數從 2 變成 1，是資產不見了嗎？
不能直接這樣判斷。可能是短暫重組或資料來源更新差異。重新核對同一網路、TxID、區塊雜湊與目前狀態；未釐清之前不要把款項視為最終可用。
已經確認，為什麼還要等？
收款服務可能要求更多確認或需要內部記帳。以該服務當期條件與款項資料為準；條件已滿足但仍未入帳時，應向收款端查詢。
等了一小時，應不應該重新轉一次？
時間本身不是重付依據。先確認原交易是否仍有效、是否被替代，以及收款端是否已偵測到。未釐清就另送獨立交易，可能兩筆都生效。
顯示失敗後，確認數增加會變成功嗎？
不會把那筆已回退的合約執行改成成功。先確認失敗原因與費用，再評估是否需要另一筆交易；不要把「被記錄」與「成功完成預期操作」混為一談。
資料與畫面核對日期：2026-09-14。本文為排查流程，不承諾交易一定可加速、取消或恢復。