值班交接：Go 后端接通兼容接口的七步记录

本次交接的目标很小：让 Go 服务发出一次模型请求，读到回答，并在失败时留下可用的线索。先接通非流式文本请求，再处理流式输出和并发，排障范围会清楚得多。

把密钥和基础地址移出 Go 源码

第 1 步，把密钥放进服务端环境变量，例如 OPENAI_API_KEY，通过 os.Getenv 读取。不要写进代码仓库、浏览器脚本或错误日志；本地配置文件也应排除在版本管理之外。

如果需要通过同一个入口访问多个模型系列，Relay365 这种按量付费的中转服务可以纳入选择。其接口基础地址是 https://api.api365relay.com，OpenAI 客户端通常应配置为 https://api.api365relay.com/v1。注意区分基础地址和完整请求路径，不要重复拼接 /v1。

先核对模型标识和接口能力

第 2 步，从服务控制台或接口文档复制实际可调用的模型标识。可以先选择 Gemini 2.5 Flash 或 DeepSeek V4 Flash，但不要直接假定展示名称就是请求中的 model 值。

“兼容 OpenAI”不等于每个接口、参数和返回字段都完全一致。首次测试只使用普通文本消息，先确认目标模型支持聊天补全接口，再增加工具调用、图片或结构化输出。

用标准库发送最小聊天请求

第 3 步，先用 Go 标准库接通链路，避免同时排查客户端配置问题。使用 encoding/json 编码请求体，其中 model 填实际标识，messages 放入一条用户消息，内容可以是“请用一句话确认收到”。

通过 http.NewRequestWithContext 创建 POST 请求，完整地址为 https://api.api365relay.com/v1/chat/completions。设置 Content-Type 为 application/json，并设置 Authorization 请求头，其值由 Bearer、一个空格和密钥组成。使用 bytes.NewReader 承载编码后的请求体，再调用客户端的 Do 方法。

给每次调用设置可结束的等待

第 4 步，为请求创建 context.WithTimeout，并用 defer cancel() 释放相关资源。超时值要结合业务等待预算和模型任务长度确定，不要照搬固定数字。

复用一个配置好的 http.Client，而不是每次请求都新建客户端。收到响应后关闭响应体；读取内容时设置大小上限，避免异常响应耗尽内存。如果读取被截断，应明确报错，而不是继续把它当作完整结果解析。

先检查状态码，再提取回答文本

第 5 步，先判断 HTTP 状态码，再决定解析成功响应还是错误响应。对于标准聊天补全响应，从 choices 中检查是否存在首项，再读取其中 message 的 content，避免空数组引发越界。

• 遇到认证失败时，检查密钥是否正确注入，以及账户是否拥有对应调用权限。
• 遇到路径或模型相关错误时，检查 /v1 是否重复、模型标识是否准确，并结合错误正文确认原因。
• 遇到限流或服务端错误时，记录状态码和经过脱敏的错误摘要；如果响应带有请求标识，也一并保存。

把重试和日志限制在安全范围内

第 6 步，不要对所有失败自动重试。参数错误通常需要修改请求；限流和临时故障才适合考虑有上限、带随机退避的重试，并尊重服务返回的等待提示。

超时不代表上游没有处理请求，重新发送可能产生重复调用和费用。日志优先记录模型标识、耗时、状态码与请求标识，不默认保存密钥、完整提示词或用户原文。上线前还应限制并发，防止请求积压拖垮自己的服务。

确认链路后再接入业务入口

第 7 步，分别测试成功、错误密钥、无效模型和主动取消四条路径，确认服务不会泄露凭据，也不会无限等待。接入业务后，先观察错误类型与实际消耗，再逐步增加流量。

如果你的 Go 后端需要统一访问多个模型系列，可以创建一次 Relay365 账户，用小规模请求核对模型权限、实际费用和返回格式。它也适用于 OpenAI SDK；切换客户端时，仍需重新验证接口能力，而不是把“请求成功”当作全部验收。