USDT 没到账，先查转出记录有没有交易哈希，再到对应网络查看结果，最后查收款平台的充值记录。转出页面的“完成”、链上的“成功”和账户已入账，可能是三个不同阶段；原因没查清前不要重复发送。
已经有链上成功记录，可以直接看收款端的四项检查；想先判断该找哪一方，查看状态对照表。
转出记录：钱还在平台处理，还是已经发出？
在自己使用的转出平台或钱包里打开这笔记录，核对数量、地址和时间，避免把另一笔相近金额的交易认错。记录中的订单编号供平台查单，交易哈希（TxID 或 TxHash）用来查询链上交易，两者不能互相替代。
仍在审核、排队或处理中，且没有明确链上记录时，先看转出方的状态说明。若提示矛盾或超过其给出的处理范围，就联系转出方查询。页面没有显示哈希，不足以证明交易绝对尚未广播。
如果实际做的是平台内部划转，可能本来就没有公开链上哈希，应查内部转账记录。显示失败或取消时，则对照余额和费用记录确认处理结果，不能只凭状态字样认定所有金额已经退回。
已有哈希，就从平台记录提供的区块浏览器链接进入，核对域名与网络后查询。保存完整哈希，后续联系收款方时也会用到。
同样的金额，未必是同一笔
先把这次转出记录单独打开。连续两次都转相同数量时，聊天里一张截图很容易对应错交易；页面上的时间也可能采用不同的时区。用完整哈希、实际网络和接收地址一起对应，金额与时间用来辅助查找，不作为唯一凭据。
订单号只在相应服务内部有意义。把它粘进区块浏览器却没有结果，不是在证明平台没发送。若记录里只有内部编号，向发送方问的是“这笔是否已经广播，能否提供链上记录”，而不是催收款方搜索一个它根本无法识别的编号。
若你操作的是站内转账，先检查收款账户或站内收款标识。强行要求每笔内部操作都给出公开哈希，只会绕远路。
- 转出记录平台是否已经发出？
- 链上记录实际发到哪里，是否执行？
- 充值记录收款平台是否记入账户？
链上记录：查状态，也要看 USDT 转给了谁
查不到时，先核对浏览器所属网络、哈希是否复制完整，以及记录是否刚生成。用 Ethereum 的浏览器查另一条链，空结果并不说明那笔交易没有发出。
查到后，查看状态和代币转账明细（Token Transfers）。以 Ethereum 为例，交易主页面的 Value 表示 ETH 数量，To 也可能是被调用的合约；它们不能直接当成 USDT 数量与最终收款人。相关含义见以太坊交易文档。核对 USDT 明细里的接收地址、数量与资产合约。
- 待确认：查看发送平台或钱包对当前状态的说明。某些钱包支持加速或替换，但不适用于所有网络和状态；平台代发的交易通常也不能由你操作。
- 执行失败：分别查看资产变动与手续费。已执行后回退的以太坊交易仍可能消耗 Gas，参见Gas 说明，不能把“失败”一律理解成零成本。
- 成功：继续核对目的地址、代币版本和所需备注。成功只说明该笔链上操作执行了，不证明它满足收款平台的入账要求。
浏览器里需要比对的是哪几行？
| 看到的字段 | 怎么用它查 USDT |
|---|---|
| Transaction Hash / TxID | 与转出记录的完整值对应，先确认没有查另一笔 |
| Status | 区分待确认、成功或执行失败，再查资产实际变化 |
| Token Transfers | 找目标代币的接收地址与数量，不只看交易主页面的Value |
| Token contract | 确认代币版本，不能只因名称叫USDT就当成所需资产 |
| Confirmations | 与收款平台当前要求对照，不套用别人的固定数量 |
例如，一笔操作的主页面写着 Value 为 0 ETH，代币转账明细却有 USDT 记录。这并不矛盾：主页面的 ETH 数量不能替代代币明细。反过来，看见某条 USDT 明细，也要核对它是不是发给了你的目标地址，而不只看同一页面上是否出现了熟悉的资产名。
一笔合约操作可能显示多条资产变动。不要把第一条、最大的一条或写着自己昵称的一条自动当作到账记录。若看不懂，让支持人员根据完整哈希说明需要看哪一条；查公开记录不需要连接自己的钱包。
浏览器显示成功后，继续往下查。这里最容易误停：成功状态解决的是执行结果，接收平台是否接受该网络、代币和备注，还需要它自己的记录。
收款端：从充值记录查这四项
打开充值历史，先找这笔交易，不只盯着总资产余额。若已经入账但不在预期位置，查看记录注明的到账账户。
- 确认是否足够：对照充值页当前要求与链上确认进度。其他人的到账速度和旧教程里的确认数，不是这笔的时限。
- 网络和资产是否支持：核对实际转入的网络、代币版本及当前维护提示。地址一样，也可能转入了平台不接受的资产。
- 实际收到多少：转出手续费从数量里扣时，收到的数额可能低于最低充值额。先看平台如何处理，别自行再转一笔期待合并。
- Memo 或 Tag 是否正确：部分充值需要它来识别账户。漏填或填错时，转向接收方的备注找回流程；已确认的交易不能事后补写备注。
如果收款端是自己的自托管钱包，则查实际网络上的地址余额，再查看钱包是否显示该网络和代币。核验资产官方合约来源，不把同名代币当成同一资产，也不向所谓“余额识别”网页提供助记词。
收款记录已有条目，余额仍然看着不对
先点开那条充值记录，读它写明的资产、数量、到账账户和状态。总资产折算值会受价格变化影响，不能拿折算金额的变化直接证明USDT有没有收到。账户分区不同、余额正在被其他操作占用，也应从相应记录解释，不先把差额都算作丢币。
若记录完全不存在，回到充值页查看本次地址和接收条件。不要为“生成一条记录”再发第二笔。特别是低于最低额的充值，不能自行假设两笔会合并计算。
把“正在等什么”写明确
三个假设情景，可以帮助区分等待对象：
- 发送方仍在审核：等的是发送方处理，链上确认计数还不是主要问题。
- 实际网络上已有交易但尚待确认：等的是相应网络上的进展，收款客服无法把它改成另一条链。
- 链上确认已满足，网络与资产也符合要求：查看收款方是否有维护、审核或其他入账提示，再按该提示联系。
这些不是时间承诺。若页面给出了预计范围，要记住从哪一阶段开始计算。不能把提币申请提交时间当作链上广播时间，再推断网络已经超时。
查到这里，该找转出方还是收款方？
| 当前情况 | 下一步 | 先别做 |
|---|---|---|
| 平台处理中，链上状态不明确 | 找转出方确认是否发出 | 重复提交转账 |
| 正确网络上待确认 | 查发送方和网络状态说明 | 照陌生教程尝试加速 |
| 链上成功，地址与资产相符 | 查收款方充值条件和记录 | 认定必须立即到账 |
| 网络、地址或备注有误 | 保存记录，联系接收地址控制方 | 向私信中的地址付找回费 |
充值到自己的币安账户，可查看官方未到账恢复说明。该入口有适用条件，不能拿它处理所有向外提币或他人账户的问题；有入口也不代表一定能找回。备注错误应按专门指引处理。
如果两边互相让你询问另一方，把问题缩到各自能回答的范围。发送方确认实际广播的网络、交易记录和发送结果；接收方确认它是否接受这笔资产，以及是否在你的账户里建立了充值记录。复制对方原话附进现有工单，比同时开许多只写“没到账”的新单更容易保留完整经过。
对方提出新的操作前，先确认它解决哪项已查出的原因。网络选错就不能用“再等一会儿”替代处理；单纯确认未满，也不该跳到向陌生地址支付找回费。若记录证明地址或备注不符，再转向相应的错误处理文章。
联系支持前，整理好这一笔记录
提供币种、实际网络、数量、目的地址、交易哈希、转出状态，以及接收页或充值历史的具体提示。若有内部订单号，注明它来自哪一方；已经有工单，就沿原工单补充信息。
例如，可以这样说明自己的情况：“转出方显示完成，链上显示成功；实际网络是……，哈希是……；收款页支持……，充值记录显示……。”未知项目留作未知，把实际提示写全，比只发一张总余额截图更有用。
公开求助不发密码、动态码、私钥或助记词。需要完整交易证明或身份材料时，只走已核验的官方渠道；别把邮箱、余额和证件拼成公开截图。
等待时看官方记录的新进展，并确认预计时间从哪个阶段起算。若另行安排付款，先告知收款方原交易仍可能完成，避免重复支付。
查单结束后记下实际结果：收到、退回、仍待处理，或官方说明无法处理。收到时记录资产和数量；退回时保存新的交易记录，不把“已受理”通知当作到账凭证。