数字货币回调状态：链上确认后回调迟迟不到，该不该盲目重试

数字货币回调状态：链上确认后回调迟迟不到，该不该盲目重试

做数字货币支付网关六年，回调状态这块我踩的坑比写的代码还多。链上交易确认不等于回调完成，中间隔着网络抖动、节点同步、状态机流转好几道坎，任何一环卡住，系统就挂在 pending 上。聊聊实际开发中最常被问到的几个问题。

回调状态机我见过最复杂的要数比特币和以太坊的差异。比特币网络确认要等六个区块，但支付网关通常两个确认就推回调，剩下的靠后台补单。以太坊这边，pending 状态可能持续几十秒到几分钟，取决于 gas 价格和区块出块速度。我之前的系统因为没区分"交易已上链"和"交易已最终确认"，导致不少商户在第三个区块还没出来时就把订单标记成失败了，后来改成了可配置确认数加超时兜底才稳住。

另一个高频问题是回调重试策略。早期我见过团队用固定间隔五分钟重试一次，八次就放弃数字货币和回调状态，结果碰上链节点维护高峰期，八次全撞在维护窗口里，商户那边订单就"丢"了。后来改成指数退避加随机抖动，上限拉到四十八小时，再叠加一条兜底逻辑：每隔两小时主动拉一次链上交易状态，哪怕回调完全没收到，只要确认数够了就直接内部补单。

还有一点容易被忽略：回调接口的幂等性。链上交易哈希是唯一的，但网络重试会重复送达，接收端必须拿交易哈希做去重，不然同一笔打款会被记账两次。我们上线初期就因为没做幂等校验，一个商户的充值回调被处理了三遍，对账时财务差点把公司告了。从那以后所有回调处理都走"查库→判重→落库"三步数字货币回调状态：链上确认后回调迟迟不到，该不该盲目重试，再没出过类似问题。