设计能在故障中存活的 SMM API 集成

每一个 API 集成的第一个版本都假定走的是顺利路径：你发一个请求，收到一个响应，订单下达成功。但生产环境会教你别的道理。网络会断、接口会超时，而最危险的故障是那种含糊不清的，在连接中断之前，那个可能成功也可能没成功的请求。为这种含糊性做好设计，才是这份工作的全部所在。

幂等性是核心防线。给每个下单请求附上一个唯一的键，并让服务器把同一个键的重复请求当作同一次操作，而非一次新的操作。如此一来，超时之后的重试就是安全的：如果原始请求已经成功，你拿回的是那个已存在的订单，而不是一次重复扣费。没有这个，每一次重试都是拿你的余额去赌博。

在其之上用退避策略叠加重试。瞬时错误（429 速率限制、503、网络重置）应当以递增的延迟和一个上限来重试，而不是瞬间猛敲。永久性错误（400 错误请求、余额不足的响应）则应快速失败并上报给人处理，因为重试它们只会浪费时间，并掩盖真正的问题。

最后，要对账。把每一次请求和响应连同它的幂等键和订单 ID 一起记录下来，并运行一个定期任务，把你的记录与面板的订单状态进行比对。对账正是用来抓出那种在面板上成功了、却没能在你这边记录下来的订单。SocialGO 的 API 会返回一致的订单 ID 和状态，正是为了让这个回路易于构建，这就是你信任的自动化与你得时刻盯着的自动化之间的区别。