按错误类型选择恢复方式

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

联系人读取返回403，教学错误详情是missing_scope contacts:read；其他情况可有参数错误、429或成功空数组。状态码、传输成功和业务成功不同，需要读取结构化详情再决定恢复。

具体做法

按当前服务/SDK已核实类型与内层错误分类，分别处理访问、参数、暂时失败和有效空数据。缺权限停止同请求重复并说明需要的访问；输入错误核对schema；429按契约有限退避；合法空结果保留为未找到。未知类别报告未分类，不从码或字符串猜通用动作。

反例

403立即重试十次，仍失败就说没有联系人；外层200内有业务error也当成功，空数组则无限重试。

改进写法

教学403读取missing_scope contacts:read，说明权限缺口并停止相同重试，访问按授权修正后再继续。参数错按schema改输入；429按有界退避；成功空数组按无匹配处理。检查外层与内层业务状态，未知错误保留详情类别与安全下一检查，不打印凭据或猜联系人内容。

为什么这样改

重复请求不能修复确定的权限或参数，成功空结果也不需要修复。错误语义与恢复相连，使拒绝、无数据和暂时失败不被混成同一重试循环。

如何验证

示意用例permission→访问缺口，invalid-input→参数定位，rate-limit→有界等待，ok/[]→无匹配，outer-success/inner-error→业务失败。检查每类保持正确状态和有限动作。

本篇不查询真实联系人，不把冻结异常类名单当当前SDK事实。

适用边界

同一码可能在不同服务有不同含义；读取错误契约而非只按403/401统一判断。写入暂时失败还可能是交付未知，需要幂等或对账，不能因为列入transient就盲重试。