调用DeepSeek API时需优先检查HTTP状态码：401表示API Key无效或缺失，须立即停止重试；429表示QPS超限，应依据Retry-After头重试；400为参数错误；500需记录X-Request-ID用于排查。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
调用DeepSeek API时遇到401、429、500等HTTP状态码，程序直接崩溃或静默失败，导致业务逻辑中断、日志缺失、用户无感知。
识别并分类常见错误码
收到响应后，第一件事是检查status_code：400系为客户端错误，500系为服务端问题。不要跳过这步直接解析JSON——很多错误响应的body仍是JSON格式，但结构与正常响应完全不同。
401 Unauthorized：API Key无效、过期或未传入Authorization头；【必须立即停止重试，否则可能触发风控限流】
429 Too Many Requests：当前QPS超限，响应头中通常含Retry-After字段（单位为秒）；
400 Bad Request：参数缺失、类型错误（如max_tokens传了字符串）、prompt为空或超长；
500 Internal Server Error：服务端异常，需记录完整请求ID（响应头X-Request-ID）用于工单排查。
Python中实现基础错误处理逻辑
方法一：用requests.status_code做分支判断
发起请求后，先if response.status_code
方法二：封装统一错误处理器
定义handle_api_error(response)函数，内部用字典映射状态码到处理动作：401→清空本地token缓存并抛出AuthError；429→读取Retry-After并sleep后重试；500→记录X-Request-ID并返回None；其他→抛出UnknownAPIError。这个函数不处理业务逻辑，只做归因和可控动作。
方法三：用装饰器自动重试429
@retry_on_status(429, max_retries=3)可包装任意API调用函数，每次捕获429时解析Retry-After，自动延迟后重发。注意：仅对幂等请求（如GET /v1/models）启用，POST /v1/chat/completions这类非幂等接口禁用自动重试。
解析错误响应体并提取关键信息
第一步：检查响应头Content-Type是否为application/json，不是则跳过JSON解析，直接记录原始text；
第二步：调用response.json()，捕获JSONDecodeError——某些网关错误会返回HTML或纯文本；
第三步：检查返回JSON中是否存在error字段（多数DeepSeek错误响应含{"error": {"message": "...", "code": "invalid_api_key"}}）；
第四步：优先读取error.code（如invalid_api_key、rate_limit_exceeded），比message更稳定，适合做程序分支；【不要依赖message做条件判断，它可能随版本变更或本地化调整】
第五步：若error.code为content_filter，说明输入或输出触发安全策略，需检查prompt是否含违规词、是否尝试生成可执行代码等高风险内容。
生产环境必须落地的三项操作
① 所有API调用必须设置timeout：requests.get(..., timeout=(3.05, 15))——连接超时3.05秒（避免TCP SYN阻塞），读取超时15秒（防止大模型卡死）；
② 每次失败请求必须记录四要素：时间戳、请求URL、请求ID（X-Request-ID）、status_code；
③ 对429错误实施指数退避：首次重试delay=1s，第二次delay=2s，第三次delay=4s，避免重试风暴压垮自身服务。
