Aptos Explorer 交易已找到却没到账：查 pending 与 vm_status
链小知 · 入门 · 核验 · 依官方文档整理
用hash或版本定位提交状态，再读success、VM错误与实际payload，排除把gas当接收数量。
开始前准备
- 准备0x交易hash、实际Aptos网络、预期收款地址与资产标识；版本号与hash分开记录。
- 适用explorer.aptoslabs.com当前查交易入口和Aptos REST按hash查询；用户交易与系统交易字段分别处理。
- 只查询公开数据不用钱包连接；公共索引API可能429，已有私有API权限与费用按实际方案。
1. 选择网络后搜准确hash
打开explorer.aptoslabs.com确认网络，在Search by address, txn, block, coin, or ANS name中粘贴完整hash。平台也允许Txn version，但不要把钱包订单编号当链上version。
记录网络、hash和结果URL。没有数据时检查发送方网络与是否已经广播；不要点Connect Wallet或Run Script来验证公开交易。
检查结果：找到同一hash，或保存明确未定位原因。
2. 区分待提交和已提交交易
查看交易type：pending_transaction代表尚未提交；user_transaction包含已提交的版本与执行字段。REST读取路径为GET /transactions/by_hash/{txn_hash}，节点先查已提交存储再查mempool。
如果浏览器没加载而接口返回pending，先保留等待状态；HTTP成功或hash存在并不表明资金已经转移。节点基地址从本人所用网络当前官方配置取得，不套example.com示例。
检查结果：type与已提交version分别记录，pending不写成功。
3. 读取success与VM错误
对已提交用户交易核对success和vm_status；success为false时保存VM原文及payload目标函数。模块/函数名称大小写有意义，不能凭模糊错误标题归因余额不足。
系统交易不按用户转账方式处理。若接口缺少这些字段，先复核实际type与返回结构，不把缺失当success:true。
检查结果：得到执行成败与VM原文；未知项可重查。
4. 核对payload与资源变化
读取用户payload的function、type_arguments、arguments，再查events/changes实际涉及的资产与地址。function通常是address::module::function，顶层sender或合约地址不自动等于最终接收地址。
只解析能确认的资产类型与精度；Move Coin与其他资产展示无法统一时留作待核对。gas_used是消耗字段，不能当APT或代币收到的数量。
检查结果：预期资产/接收人和可见变化逐项核对。
5. 处理限流并保留检查时间
当前Explorer页面可能显示HTTP429，并区分共享匿名额度或应用额度。降低访问频率并按当前提示等待；本人已有API配置可按官方入口管理，不把限流错误当链上失败。
最终记录网络、hash、version/type、success、vm_status、资产流向与时间。网页只能读到部分信息时，把缺项列清，不能承诺平台已到账。
检查结果：交付状态与错误记录，区分访问问题和执行问题。
怎样确认完成
- 准确定位type/version、执行状态与无法解析的资产变化。
- 依据官方文档整理，尚未完成真实账户查询或交易行为验收。
常见错误与边界
- pending与执行失败的处理不同。
- gas_used无直接人类资产单位，不能作转账净金额。