汽车配件API错误码怎么处理-201到220业务失败与重试边界

汽车配件 API 报错时，应先区分输入、车型锁定、权限和服务状态问题，再决定修参数、转人工、降级或重试，不能对所有失败统一重试。

先建立错误分类

错误码	文档含义	建议动作	是否适合自动重试
201	VIN 不正确	校验长度、字符和录入内容	否，先修正输入
202	VIN 无法锁定车型	提示选择车型或人工确认	否，不能盲重试
203	零件名太短	补充至少两个字的名称	否，先补参
204	车型 ID 错误	从车型 API 重新获取合法 ID	否，先修 ID
205	零件号为空	传入零件号或改用零件名称	否，先修参
220	没有信息	展示无匹配并切换查询条件	通常否
101 至 103	appkey、过期或权限问题	检查密钥和产品权限	否
104	请求超过次数	停止继续调用，检查额度、重置周期或产品权限	否，盲目退避不会恢复额度
106	IP 请求频率超过限制	降低并发、排队；确认限流窗口后做有上限的延迟重试	有条件
105、107、108	IP 禁止、维护或停用	告警、降级、确认服务状态	否

错误码和字段以车型零件搜索 API 文档当前页面为准。其他 API 的错误码不能直接套用到这个接口。

输入类错误：修正后再发一次

201、203、204、205 都属于请求本身不满足条件。服务端应把用户可修正的提示说清楚：VIN 字符是否抄错、车型 ID 是否来自车型大全 API、零件名称是否达到最小长度、零件号是否真的传入。不要把这些错误包装成“网络异常”，否则客服和开发都会重复重试同一个坏请求。

VIN 无法锁定：不要用猜测的车型继续查

202 的关键不是“再请求几次”，而是 VIN 与车型之间没有建立可用锁定关系。可以让用户改用车型选择，或进入人工核验；一旦选择了车型，必须把新的 carid 与原 VIN、确认来源和时间一起记录。没有锁定结果时，不应直接把某个相近车款的零件返回给客户。

220 没有信息：设计查询降级路径

220 不一定表示系统故障，可能是名称、编号和车型组合没有匹配。可按以下顺序降级：

保留已确认的车型，改用更标准的零件名称。
如果用户有 OE 或品牌件号，切换到对应编号入口。
展示候选结果前再次核对品牌、单位和车型。
仍无结果时记录查询条件，转人工或供应链目录核实。

降级是改变查询条件，不是无限次重复同一个请求。

鉴权、限流和维护：按系统事件处理

101 至 103 需要检查 appkey 是否为空、过期或没有权限。104 表示请求次数超过限制，应暂停任务并检查额度、套餐或重置周期，继续指数退避不会自动恢复可用次数。106 是 IP 请求频率超过限制，适合降低并发、进入请求队列，并在确认限流窗口后做有上限的延迟重试。105、107、108 则应触发监控告警，并在前端显示服务暂不可用或切换合规缓存。密钥只在服务端使用，日志中仅保留哈希或末几位标识。

一个通用的处理骨架如下：

INPUT_ERRORS = {201, 203, 204, 205}

def handle_api_result(data):
    code = data.get("status", 0)
    if code == 0:
        return {"state": "success", "data": data.get("result")}
    if code in INPUT_ERRORS:
        return {"state": "fix_input", "message": data.get("msg", "请检查查询条件")}
    if code == 202:
        return {"state": "vehicle_unresolved", "message": "VIN 未锁定车型，请选择车型或人工确认"}
    if code == 220:
        return {"state": "no_info", "message": "当前条件没有匹配信息"}
    if code == 104:
        return {"state": "quota_exhausted", "message": "请求次数已超限，请检查额度或重置周期"}
    if code == 106:
        return {"state": "throttled", "message": "IP 请求频率超限，请排队并按限流窗口重试"}
    return {"state": "alert", "message": "接口权限或服务状态异常"}

这段代码只是错误分层示例，没有调用真实接口；上线前应按你实际使用的 API 文档补充字段映射、退避上限和告警渠道。