同一笔交易在不同节点与浏览器上状态不一致

30 秒回答

交易未被打包时，receipt 查询返回 null，这个结果表示尚无回执，而不是交易失败；交易查询与 receipt 查询返回的是查询节点在查询时刻的视图，不同节点与服务的可见性可能不一致。确认状态以 receipt 与区块推进情况为依据。实现差异与工程取舍见深入回答。

【协议保证】交易未被打包时查询收据得到空结果（依据：EIP-1474 §eth_getTransactionReceipt 的说明）。

【协议保证】交易查询与收据查询都以交易哈希为输入（依据：EIP-1474 §eth_getTransactionByHash、§eth_getTransactionReceipt）。

【实现行为】内存池可见性、广播传播速度与查询响应因节点与服务商而异，同一时刻不同 RPC 的结果可能不一致（依据：因节点与服务商而异）。

【工程经验】确认状态以 receipt 为依据，并进一步结合区块确认深度判断；单次 pending 查询为空不足以判定交易丢失（依据：工程经验，无规范依据）。

【工程经验】多 RPC 场景下定义主节点与对账策略：以拿到 receipt 的节点结果为准，其他节点用于可用性备份（依据：工程经验，无规范依据）。

【工程经验】切换 RPC 后仍可用同一交易哈希查询，但展示状态要重新以新拿到的 receipt 为准，避免混用两段视图（依据：工程经验，无规范依据）。

【工程经验】重复广播同一笔交易可能产生多条传播路径，需要去重与幂等处理，避免界面重复展示（依据：工程经验，无规范依据）。

【工程经验】对用户的到账时间承诺给出区间而不是时点，并在区块确认推进时更新界面状态（依据：工程经验，无规范依据）。

【工程经验】把「未在本地 RPC 查到」与「交易被替换或丢弃」区分开：前者属于视图问题，后者需要结合 nonce 与替换检测判断（依据：工程经验，无规范依据）。