DeepSeek API 错误排查：状态码、重试与线上监控

可靠的 API 集成需要先区分“修改请求后再试”和“等待后重试”。对所有错误无脑重试，会放大流量、延长故障并产生重复业务操作。

一、按状态码处理

• 400：请求格式错误。检查消息结构、工具调用上下文和 JSON。
• 401：认证失败。检查密钥是否存在、是否被撤销，不要把密钥写入日志。
• 402：余额不足。应告警并停止自动重试。
• 422：参数无效。对照当前模型的参数范围修正请求。
• 429：超过并发限制。降低并发、排队并采用带抖动的指数退避。
• 500 / 503：服务端异常或过载。可有限重试，并准备降级路径。

二、一个保守的重试框架

async function withRetry(run, maxAttempts = 3) {
  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    try {
      return await run();
    } catch (error) {
      const status = error.status;
      const retryable = status === 429 || status === 500 || status === 503;
      if (!retryable || attempt === maxAttempts) throw error;

      const delay = Math.min(8000, 500 * 2 ** (attempt - 1));
      const jitter = Math.random() * 250;
      await new Promise(resolve => setTimeout(resolve, delay + jitter));
    }
  }
}

三、生产环境要监控什么

至少记录状态码、请求 ID、模型名、端到端耗时、重试次数、Token 用量和调用方服务。对 401、402 和持续 5xx 建立告警；日志中对用户输入、输出及工具参数做脱敏。

如果请求会产生付款、发信或写数据库等副作用，应在业务层增加幂等键，避免网络重试造成重复执行。