开发环境“能返回一句话”只证明最短链路可用，不代表应用已经适合生产。上线前需要验证失败路径、密钥边界、流式完整性、成本记录和模型切换，而不是只测一次成功请求。
开始前检查
为生产环境单独准备：
- 独立 API Key，不和个人测试共用。
- 固定的真实模型 ID，并准备可控的替代模型。
- 一组脱敏测试输入，覆盖短请求、长请求、流式和工具调用。
- 能查看状态码、请求 ID、耗时和重试次数的日志。
配置步骤
1. 连接与认证
- Base URL 最终没有重复
/v1/v1。 - API Key 只存在于服务端环境变量或密钥系统。
- 测试 401 时不会自动无限重试。
- Key 可以独立撤销和轮换。
- 前端、日志、报错页面和监控事件不会暴露完整 Key。
2. 模型与协议
- model 使用
/v1/models或控制台返回的真实 ID。 - 分别验证 Chat Completions、Responses 或目标客户端实际依赖的接口。
- 普通文本成功后，再单独验证流式输出、工具调用、图像输入等能力。
- 模型不可用时，应用能给出明确错误，而不是静默切换后返回不同质量结果。
3. 超时与重试
建议分别配置连接超时、读取超时和任务总时限。重试必须有最大次数，并加入随机抖动，避免大量请求同时再次冲击服务。
| 场景 | 默认处理方向 |
|---|---|
| 400、401、model not found | 修正请求，不自动重试 |
| 429 | 检查配额与并发，读取 Retry-After（若有），有限退避 |
| 部分 5xx | 记录请求 ID，有限重试或切换备用路径 |
| 网络中断 | 先判断请求是否可能已执行，再决定是否重试 |
有副作用的工具调用必须先设计幂等键或去重机制。否则一次“重试”可能导致重复发消息、重复写入或重复扣费。
4. 日志与可观测性
每次请求建议记录：
timestamp, request_id, model, endpoint, status,
latency_ms, first_token_ms, input_tokens, output_tokens,
retry_count, final_result日志中不要保存完整 API Key、用户隐私、未脱敏文件内容或完整提示词。确需留存时，应设置访问权限、保存期限和删除机制。
5. 成本与容量
- 记录请求次数、输入输出用量和失败重试。
- 为单用户、单任务和单日设置预算或请求上限。
- 用真实业务样本估算，不只使用一句话测试。
- 价格、模型开放状态和计费规则以控制台实时信息为准。
6. 发布与回滚
- 保留上一版配置和模型路由。
- 先灰度少量流量，再逐步放大。
- 能通过配置关闭流式、工具调用或高成本模型。
- 回滚不依赖重新发版。
- 客服排错信息不包含用户敏感数据。
常见问题
有备用模型就算完成容灾了吗
不算。备用模型可能有不同的上下文、工具调用、结构化输出和成本特征。需要用同一组业务测试验证，并明确什么条件下切换、如何告知用户以及何时恢复。
应该把超时设得越长越好吗
不是。过短会误杀长任务，过长会占用连接和并发。应根据请求类型设置不同策略，例如普通问答、长文本生成和 Agent 工具任务分别配置。
上线前最重要的一项是什么
没有单一答案。最低限度是：密钥不泄露、失败不会无限重试、请求可定位、成本可观察、配置可回滚。这五项缺一项，问题发生后都很难快速止损。
下一步
把本文清单写入发布流程，每次更换模型、SDK、代理层或超时策略时重新执行。不要把一次通过的测试当成永久结论。