直接用 net/http 调 openai api 易踩四大坑：无重试致 429 panic、未复用连接池致端口耗尽、大响应体一次性解码引发 gc 频繁、header/超时配置错误致静默失败。
直接用 net/http 发请求会掉进哪些坑？
不推荐从零手写 HTTP 客户端调 OpenAI API——看似简单，实则埋雷密集。生产环境里最常炸的几个点：
-
429 Too Many Requests一来就 panic，没重试逻辑，下游服务直接雪崩 - 每个请求新建
http.Client，连接池没复用，TIME_WAIT堆满，Linux 端口耗尽报dial tcp: too many open files - 大响应体（比如长对话流式返回）用
json.Unmarshal一次性解码，内存峰值翻倍，GC 频繁卡顿 -
Content-Type漏设、Authorization头拼错格式（漏Bearer前缀）、timeout设成 0 或无限，全都会静默失败
选哪个 SDK？openai-go vs go-openai vs 自己封装
官方 openai-go 是当前最稳的选择：API 同步快、结构体字段全、支持 streaming 和 function calling。但它默认的 http.Client 不开连接池，超时也没分层（request vs connect vs read），得自己包一层。go-openai 中文文档多，但 2025 年后部分新字段（如 response_format、tool_choice）更新滞后，容易踩空。
自定义封装只在两种情况值得做：要深度控制 token 计算逻辑，或必须嵌入企业级 tracing/metrics。其他场景纯属重复造轮子。
怎么配置一个抗压的 http.Client？
OpenAI 官方建议每分钟 3500 请求（Pro tier），但没告诉你客户端扛不住。关键不是加 goroutine，而是压住连接生命周期：
- 设置
MaxIdleConns和MaxIdleConnsPerHost至少为 100，避免频繁建连 -
IdleConnTimeout设为 90s，比 OpenAI 的 keep-alive 默认值（75s）略长，防被 server 主动断 - 必须设
Timeout（总超时）、Transport.TLSHandshakeTimeout（握手）、Transport.ResponseHeaderTimeout（header 回来前），三者缺一不可 - 别用全局默认
http.DefaultClient，它没有超时，会 hang 死整个 goroutine
示例初始化：
client := &http.Client{<br> Timeout: 30 * time.Second,<br> Transport: &http.Transport{<br> MaxIdleConns: 100,<br> MaxIdleConnsPerHost: 100,<br> IdleConnTimeout: 90 * time.Second,<br> TLSHandshakeTimeout: 10 * time.Second,<br> ResponseHeaderTimeout: 15 * time.Second,<br> },<br>}
sync.Pool 优化 Message 创建真有用吗？
有用，尤其在高频短对话（如客服机器人）场景下。ChatCompletionMessage 结构体虽小，但每轮对话至少新建 2 个（user + assistant），QPS 上千时 GC 压力明显。
- 用
sync.Pool复用*openai.ChatCompletionMessage，可降低约 18% GC 频次（实测 pprof 数据） - 注意别把
Role/Content设成指针引用，否则 Pool Get 后不清零，脏数据会串话 - Pool 不适合长期存活对象（比如带 channel 或 mutex 的结构），Message 符合轻量、无状态特征，正合适
典型写法：
msgPool := sync.Pool{New: func() interface{} {<br> return &openai.ChatCompletionMessage{}<br>}}<br>// 使用时<br>msg := msgPool.Get().(*openai.ChatCompletionMessage)<br>msg.Role = "user"<br>msg.Content = userInput<br>// …调用完记得放回（如果后续还要复用）<br>// msgPool.Put(msg)
Go SDK 接 ChatGPT 最容易被忽略的其实是错误分类处理——比如 401 Unauthorized 要告警密钥失效，400 Bad Request 要打日志查 prompt 格式，而 503 Service Unavailable 得走降级逻辑。这些没法靠 SDK 自动区分，得在 if err != nil 后手动 inspect resp.StatusCode 和 error body。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
