一个失败的请求可能需要延迟、修正字段或更换凭据。Bird 的错误响应提供了字段，帮助你的处理程序选择相应操作。
应该使用哪些错误字段？
使用 type 进行宽泛处理，使用 code 进行特定恢复。Bird 将这些字段放在顶层 error 对象中。
type 将故障分组，例如验证、身份认证和请求速率限制。code 标识具体故障，例如 E01001 表示字段验证错误。
Bird 不会重命名或复用任何错误码。已废弃的错误码仍然保留，因此现有的错误码匹配始终保持其含义。
可以显示或记录 message，但不要匹配其文本。措辞可能会更改，而你的处理程序需要处理的故障不会改变。
name 使日志更易读。doc_url 链接到该错误码的文档。当操作失败时，将 code、name 和 request_id 一并记录。
哪些故障应该重试？
使用有限策略重试临时故障。在重新尝试之前先修正输入和凭据问题。当同一状态码可能需要不同操作时，检查具体的错误码。
| 响应 | 默认操作 |
|---|---|
429、E01003 | 等待 Retry-After，然后重试。 |
500、502、503 或 504 | 以递增延迟重试，并设置尝试次数上限。 |
501 | 停止并检查服务器支持哪些操作。 |
401 或 403 | 在重试之前修正凭据或其权限。 |
| 字段验证或无效输入 | 根据响应中标识的字段进行修正。 |
409、E01004 | 等待正在进行的操作完成后再重试。 |
409、E01005 | 修正使用不同输入复用幂等键的问题。 |
重试同一写操作时保持相同的幂等键。超时或服务器故障并不能证明原始操作没有执行。
当重试预算耗尽时停止，并记录最终错误。无限重复未更改的请求可能掩盖需要人工介入的故障。
如何处理字段验证错误？
读取 E01001 ValidationError 上的 details 数组，将每个条目与其 param 关联。在受影响的字段旁显示该条目的 message。
不要解析这些消息来识别字段或故障。它们的措辞可能会更改，与顶层消息一样。
格式错误的请求可能返回 E01002 InvalidRequest。使用其文档中的恢复方式，而不是假设每个输入故障都包含字段级详情。
响应能告诉我如何恢复吗？
某些错误包含 remediation（人类可读的下一步操作）或 next（可尝试的有序操作列表）。
当修复建议有助于用户纠正问题时，将其展示出来。例如，授权失败可能需要具有额外权限范围的凭据。
自动化处理程序可以使用 next 选择恢复操作。但在执行之前，仍需具备该操作所需的输入和权限。
vendor_code 标识下游故障，例如 SMTP 响应或支付拒绝。当恢复操作依赖于该提供方时，请查阅其错误码。
遇到不熟悉的错误码该怎么办？
保留一个默认分支来记录故障，避免崩溃或无限重试。随着 API 的增长，新的错误码和类型可能会出现。
在适当的情况下应用已知的基于状态码的重试策略。否则，停止并将该错误码及其请求 ID记录下来以供排查。
错误指南记录了错误响应结构。错误参考列出了各个错误码及其恢复指引。
简而言之
匹配错误码而非消息文本。
Bird 不会重命名或复用错误码，但人类可读的消息文本可能会更改。
有限度地重试临时故障。
遇到请求速率限制时等待，遇到临时服务器故障时进行退避。对同一写操作的重试应保持相同的幂等键。
读取验证详情。
E01001在details中携带字段问题。使用每个param将其消息与受影响的输入关联。为未知错误保留兜底处理。
记录不熟悉的错误码及其请求 ID，以免新故障破坏你的处理逻辑。