接口报错之后：哪类错误码可以自动重试，哪类必须停下来核对

自己写过交易脚本的人都有过这种时刻：下单请求发出，网络抖了一下，返回了一个看不懂的错误码——重试吧，怕成交了两笔；不重试吧，怕这单根本没出去。错误处理是交易所接口接入里最少被认真对待、又最容易亏钱的一段。可靠的办法不是背下某个平台的码表，而是先建立一个三分法：哪些错误可以安全重试、哪些重试一万次也不会变对、哪些必须先停下来核对状态。机制说明撰写于 2026 年 9 月，各家平台的错误码互不相同，不存在通用对照表，具体语义一律以对应平台的开发者文档为准，本文不构成投资建议，也不构成对任何接入实现的承诺。

第一类是可重试类，特征是请求大概率没有产生状态变化，或者平台明确设计了幂等保护。最常见的是网络层超时与网关返回的服务不可用：连接断了、对端网关过载，请求根本没进撮合引擎，重发通常安全。但要注意这个大概率：一旦超时发生在请求已抵达但未返回之间，你的脚本并不知道撮合引擎是否已经收下它，重试就可能成交两笔。严肃的接入做法是给每笔委托带幂等标识，让平台侧帮你去重；没有这个条件时，超时后的正确动作是先查这笔委托的当前状态再决定补单，而不是直接重发。另一类是可退避重试的频控：触发限速后应当按响应里的恢复信息退避，最糟的应对是并发地快速连环重试——那只会让窗口惩罚更长。

第二类是不可重试类：参数、精度、权限、余额不足。这类错误是对确定事实的陈述——价格不符合最小报价单位、名义价值低于交易对要求、这把密钥没有现货下单权限、可用余额确实不够。重试一百次，事实不会变，脚本只会把日志刷满。工程上应当把这类码归入立即失败并抛出人可读的提示，常见根因包括交易对规则改版、精度换算写错、以及把错误产品的密钥用在了这个产品上。

第三类最耗人：需要核对类。典型是请求被拒但账户状态并不清晰——自带的模拟撮合类订单在无法成交时有的平台直接拒单、有的行为取决于时效参数设置，风控相关的拒绝则可能牵连整个账户的功能开关，不能当成一次普通的下单失败。处理规则只有一条：先回查真实状态，再做任何动作。账户页、订单历史、持仓页是你的一手信息源，论坛和社群里的经验帖不是。

给自建系统三条落地建议。第一，把错误码表当成交付物的一部分：为每个你实际遇到的码写明三类归属、重试策略与日志级别，定期复核，接口大版本变更后重新过一遍。第二，断线恢复要先对账：策略重启的第一动作是查询未决委托与账户变动，把平台侧的真实状态同步进来，再考虑接回信号——把重启当成与撮合引擎断开了联系，而不是睡了一觉。第三，给自己留一条止损纪律：当同一个错误码在短窗口内反复出现，自动暂停并通知人，而不是让它带着错误假设继续下单。

最后做一个边界说明：接口层的可靠性不等于资金安全，密钥只开需要的权限、绑定服务器地址、设过期时间，这些账户侧动作与错误处理同样重要。错误码文档是每个平台公开得最彻底、也最少被读完的部分——把它读完，本身就能过滤掉大部分深夜事故。本文为机制与工程习惯说明，所有平台的具体码值、限速参数与幂等机制以开发者文档为准。