最佳实践
上线前
先建立可排查的请求边界
先让单个最小请求稳定，再逐步增加上下文、并发和运行时间。不要把所有变量一次改完。
✓ 长输出优先使用流式输出（
stream: true），并分别设置连接、首字节和总任务超时。✓ 大项目分阶段处理，不要一次发送完整仓库、历史会话和大量日志。
✓ 每个项目和环境使用独立 API 密钥，便于统计、限额、轮换和禁用。
✓ 从低并发开始逐步增加；用队列设置上限，不创建无界并发。
✓ 先记录请求时间、模型 ID、接口路径、状态码和追踪标识，再记录经过脱敏的错误内容。
✓ 重要任务先小范围测试，确认调用日志和费用正常后再长时间运行。
出现异常请求、API 密钥泄露或不认识的调用日志时，先在控制台禁用对应密钥并创建新密钥。不要在工单、截图或聊天记录中发送完整密钥。
重试边界
只重试可能恢复的错误
重试不是越多越好。重复生成可能产生额外费用；已经收到部分流式输出时，不要自动重放整次请求。
可以有限重试429、部分 5xx、网络连接中断或网关超时；优先遵循
Retry-After。不要自动重试400、401、403、404。先修正参数、密钥权限或接口路径。
停止条件达到最大次数、已经收到部分输出、超过总任务时限，或同一错误持续出现。
指数退避伪代码
最多尝试 3 次
如果响应包含 Retry-After：按它等待
否则等待：基础间隔 × 2^尝试次数 + 随机抖动
仅在 429、可恢复的 5xx 或网络错误时重试
如果已经收到部分流式输出：停止自动重试并记录日志
如果是 400、401、403、404：立即停止，修正配置
安全与日志
密钥隔离，日志脱敏
密钥存放放在服务端密钥管理、部署平台 Secret 或本地环境变量；不要进入前端包和 Git 历史。
密钥隔离开发、测试、生产分开；项目之间分开。泄露时只影响一个范围。
日志允许保留API 密钥名称或末尾少量字符、模型 ID、接口路径、状态码、时间、请求追踪标识。
日志必须删除完整 Authorization 请求头、完整 API 密钥、用户隐私、未授权的提示词和文件内容。
联系客服前先确认：最小请求能否复现、调用日志是否有记录、错误是否发生在同一模型和接口路径。这样比只发送客户端弹窗更容易定位。