现象：App 有进度，浏览器一片空白
典型路径：
- 提现详情写着「处理中 / 广播中 / 已发送」
- 复制一串字符去区块链浏览器
- 得到 Not Found、无效哈希或空白页
这不等于资产已消失，更常见是：查错对象、状态语义理解偏差、或链上尚未可被浏览器索引。
本文提供 分层排查清单：先分清业务态与链上态，再按频率从高到低排除误查，最后整理工单材料。适用于 OKX、币安等平台的通用逻辑；按钮文案与最终状态 以官方实时页面为准。
注册入口：
相关阅读：
第一层：对齐三种「成功」
| 层级 | 你在 App 里可能看到的 | 浏览器侧通常怎样 |
|---|---|---|
| 业务受理 | 已提交、审核中、处理中 | 往往 无 TxID，搜什么都没有 |
| 广播/发送 | 已广播、已发送、广播中 | 可能短暂 Not Found，或仅 mempool |
| 确认入账 | 成功、已完成 + 确认数 | 有出块记录，确认数随时间增加 |
操作要点： 点进提现 详情，确认有没有标注为 TxID / TxHash / 交易哈希 的字段，以及 网络名称全文。不要把「成功」两个字当成已经上链。
第二层：排除「查错」——最高频
1. 用错区块链浏览器
TRC20 去 EtherScan、ERC20 去 TronScan、BTC 用错浏览器——必然查无。
网络名以提现详情为准，对照：
2. 把订单号 / 流水号当成 TxID
平台内部 ID 不是链上哈希。只有明确 交易哈希 字段才拿去搜。
无 TxID 时：停留在第一层，等详情更新或联系官方客服，而不是反复刷新错误浏览器。
3. 复制缺字、多空格、手动换行
哈希少一位即无效。从 App 一键复制，粘贴到纯文本笔记再搜。
4. 搜成了合约地址或钱包地址
应搜索 交易哈希。代币合约地址、自己的充值地址，与「这一笔提现 tx」不是同一类查询对象。浏览器用法见 blockchain-explorer-deposit-check。
5. L2 / 侧链与主网混淆
详情写的是某 L2 或特定网络时，必须用对应浏览器或筛选条件，而不是默认「主流主网」。
第三层：链上真实延迟与队列
| 情况 | 可能含义 | 用户侧动作 |
|---|---|---|
| 有 TxID，浏览器稍后才出现 | 索引延迟 | 稍后重试；换备用浏览器 |
| 显示 pending / 未确认 | 仍在 mempool 或确认中 | 记录时间，避免重复提现 |
| 长期 pending | 网络拥堵或费用策略等（视链） | 以平台说明为准；用户通常不能自行 RBF |
| 无 TxID 较久 | 审核、风控、批量出款 | 官方工单查询 |
| 维护/暂停窗口 | 出款与索引都可能异常 | 见 deposit-withdraw-paused |
不要编造或迷信「一定 XX 分钟到账」。 拥堵与平台策略都会改变体感时间，以页面确认数与客服答复为准。
并行阅读：crypto-withdrawal-pending、withdrawal-broadcast-not-found。
第四层：按顺序执行的清单（建议打印）
- 截图 提现详情全页（含时间、状态、网络）
- 确认 网络名称 全文，写下对应浏览器
- 确认字段名是 TxID 再复制；若无 TxID，标注「仅有订单号」
- 在正确浏览器粘贴查询
- Not Found：等待一段时间后重试；换一家同网络浏览器
- 若 pending：记录首次可见时间，对照是否持续推进确认数
- 若 success：核对 to 地址 是否为你的收款地址；Memo 币种另核 tag
- 仍无法解释：走 官方 App 内客服，不要私聊
提现前流程化可减少事后焦虑：okx-withdrawal-checklist。
第五层：工单材料清单
- 平台提现 订单号
- TxID（若有；没有就明确写「详情尚未生成」）
- 币种、数量、网络全文
- 目标地址与 Memo/Tag（如有）
- 浏览器查询截图（含 URL 与时间）
- 收款方若是其他交易所：对方充值记录空窗或延迟说明截图
只通过官方帮助中心。不发送 2FA、短信码、助记词。假客服话术见 telegram-fake-support-scam。
链上成功但「对方没到账」
说明币已进入某地址，问题转到 入账规则：
- Memo/Tag 错或漏 → withdrawal-memo-optional-or-required、crypto-memo-tag-wrong-recovery、forgot-memo-tag-recovery-path
- 收款平台确认数未满或风控延迟
- 你提到了自己另一钱包/子账户，看错账户
- 错网络路径 → wrong-network-deposit-recovery
让收款方用 同一 TxID 查询，而不是要求你「再提一笔试试」。
场景示例
场景 A：OKX 显示广播中，两小时无 TxID
可能仍在出款队列或安全审核。保留订单号提交工单；避免因焦虑重复提交多笔大额。相关：okx-risk-control、new-device-login-wait-24h。
场景 B：币安详情有 TxID，TronScan 成功，他所未入账
把成功页给收款平台；核最小充值、Memo、是否暂停充值。
场景 C：自己提到钱包，浏览器成功但钱包 UI 无余额
检查是否添加正确代币合约、是否同一网络、是否需刷新；不是「再从交易所提一次」能解决的显示问题。
场景 D：维护刚结束，全网都慢
先读公告与网络状态，小额验证通道恢复后再大额。见 exchange-maintenance-asset-safety。
场景 E：同一网络两笔，一笔浏览器可见一笔不可见
分别记录两笔的订单号与 TxID，不要假设「批量命运相同」。可见的那笔先核 to 地址；不可见的按 L1–L3 单独走。分批出金习惯见 split-withdrawal-security-ops、multi-address-withdrawal-safety。
场景 F：内部转账 / UID 转错当成链上广播
部分「转账」实际是平台账本划转，不会产生公链 TxID。若你走的是 UID/内部转，浏览器本来就查不到哈希——应查站内记录，而不是公链浏览器。相关：internal-transfer-uid-wrong、okx-account-transfer、binance-account-transfer。
情绪与操作纪律（容易被忽略的一层）
浏览器 Not Found 时，最伤的是 重复提交大额提现 与 点进假加速链接。建议纪律：
- 同一笔异常只保留 一个 主工单线程，补充材料而不是开十个重复单
- 未确认上一笔终态前，不把剩余仓位「再提一遍碰运气」
- 所有链接只从 App 内帮助中心进入
- 与家人/同事协作时，统一一个笔记文档记录 TxID，避免口头传错哈希
充提主流程回顾：
预防：让「查得到」变成默认结果
- 提现成功后立即把 TxID 存本地笔记
- 大额先小额，确认全流程再放量
- 固定常用网络与对应浏览器收藏（官方来源）
- 地址进白名单，减少贴错：binance-withdrawal-whitelist、withdrawal-whitelist-waiting-period
- 冷钱包路径预先演练：okx-to-cold-wallet、binance-to-cold-wallet
- 费用与网络选择心里有数（以页面实时报价为准）：okx-withdraw-fee-guide、binance-withdraw-fee
分层排查速查表
| 层级 | 关键问题 | 通过标准 |
|---|---|---|
| L1 状态 | 有没有 TxID？ | 有则进 L2；无则盯平台/工单 |
| L2 查询对象 | 网络、浏览器、哈希是否正确？ | 正确浏览器出现记录或明确 pending |
| L3 链上进展 | 确认数是否在增加？ | 达收款方要求或平台显示完成 |
| L4 入账 | to 地址与 Memo 是否匹配收款方？ | 收款方余额或充值记录更新 |
| L5 人工 | 材料是否齐全且走官方？ | 工单号可追踪，拒绝私聊加速 |
总结
- 广播中 ≠ 浏览器必有记录；先分业务态与链上态。
- Not Found 优先查：错链、错 ID、复制错误、索引延迟。
- 无 TxID 时，工单对象是平台出款状态，不是「换个浏览器碰运气」。
- 链上成功未入账，转向 Memo/收款方规则，切勿盲目重提。
- 拒绝一切「加速上链」转账话术。
本文仅供信息参考，不构成投资建议。加密资产交易与提现存在风险，请独立判断并遵守当地法规。到账时间、链上费用与确认数均以交易所官方及区块链实际数据为准，本文不给出对所有网络适用的固定分钟或费用承诺。