企业官网建设流程全解析

这两年做AI应用落地，Go社区里问得最多的就是“怎么调大模型接口”。倒不是Go生态缺库，而是各家大模型基座的API风格实在太分裂——OpenAI一套、Anthropic一套、Google又一套，参数名、鉴权头、流式协议全不一样，光是把它们统一起来就够写一篇长文。这篇文章我就用Go代码把OpenAI兼容接口、Claude、Gemini这三类最常见的基座挨个调一遍，顺便把我在生产环境踩过的坑一并交代清楚。内容不绕弯子，适合正在写AI网关、Agent编排服务、或者想把LLM能力集成进后端系统的朋友直接参考。

1. 为什么用Go调大模型：需求场景与整体思路

1.1 什么场景下你会用到Go调大模型

先说需求从哪来。现在大模型调用早就不只是Python脚本里跑个demo了，生产环境里经常是Go写的后端服务需要去对接模型服务商。典型的场景有这么几个：一是企业内部做AI网关或统一代理层，前端各种应用都走这一个入口，后端要把OpenAI、Claude、各家国内模型聚合成一套统一协议；二是Agent编排系统，也就是常说的智能体框架，Go这边虽然没有Python那种丰富的Agent生态，但胜在并发模型成熟，几百个任务同时跑也不慌，非常适合做调度和编排层；三是IM机器人和自动化流水线，比如飞书机器人、工单自动回复这类应用，通常就是Go常驻进程，用户一发消息就触发一次模型调用。

这些场景有一个共同特点：调用频率高、对延迟敏感、还要处理流式输出。Python在这种场景下不是不行，但Go在资源占用、部署便捷性和并发处理上确实有自己的优势。很多团队的选择是底层模型调用用Python写原型，最终交付时换成Go来做服务化，所以“用Go调大模型”成了一个很实际、很高频的需求。

1.2 不同大模型基座的API风格差异

把OpenAI、Claude、Gemini放在一起对比，你会发现它们虽然都是“发HTTP请求、拿JSON响应”，但细节差异能坑死第一次接入的人。只要对接过两家以上，基本都会经历“消息格式完全对不上”“鉴权头位置不一样”“流式解析无从下手”这类问题。我列一个简单的对照表，看一眼就能明白差距有多大。

这套差异不是设计上的任性，而是各家对“对话模型”的理解不同。OpenAI定义了一套业界事实标准，后来大量模型服务商兼容了这套格式；Claude则强调system消息的独立地位，并且要求max_tokens必须显式传入；Gemini则把API设计成了更传统的REST风格，鉴权key直接放在URL上。理解了这些背后的思路差异，就比较容易记住每个接口的写法了。

1.3 一次完整调用背后的通用流程

不管调哪家基座，一次完整调用拆开来看都是固定的几步：构造HTTP请求、设置鉴权信息、序列化请求体、发送请求、读取响应、反序列化结果。如果你还需要流式输出，就得额外处理SSE（Server-Sent Events）协议，一行一行地解析事件流。这些步骤本身不复杂，只是每家每个步骤的细节都不一样。

我在实际项目中，一般先把这些共性抽出来：统一管理API Key、统一配置超时和重试、统一日志输出格式。然后再针对每家的差异做适配层。这样就算后边又加了一个新的模型基座，改动量也控制在一个文件以内。这篇文章后面的代码示例，也基本按照“统一骨架 + 各家差异”的方式来组织。

2. 准备工作：环境、依赖与统一调用骨架

2.1 Go环境与依赖管理

开始写代码之前，先把环境准备好。我用的是Go 1.22版本，Go 1.21以上都行，低版本的话主要是http.ResponseController这类新特性用不了，影响不大。项目初始化就是常规操作：

mkdir llm-example && cd llm-example go mod init llm-example

依赖方面，这一整套代码我刻意不引入任何第三方SDK，只用标准库的net/http、encoding/json、bufio、io这些包。原因后面会专门讲，这里先记住一个结论：大模型调用本质就是HTTP加JSON，标准库完全够用，而且出了问题你能直接看到底层细节。

API Key的管理建议用环境变量，不要硬编码到代码里。我习惯在项目根目录放一个.env文件，然后用os.Getenv读取，方便本地开发。线上环境直接用Kubernetes的Secret或者配置中心注入环境变量，这样代码统一。

import ( "os" ) func getEnv(key string) string { return os.Getenv(key) }

2.2 统一HTTP客户端配置

调用大模型API，最忌讳的就是每次请求都新建一个http.Client。这里有两个坑：一个是频繁创建连接会浪费TCP握手开销，另一个是默认的http.Client没有超时限制，一旦上游服务卡住，你的goroutine就全堵在那了。

生产环境我一般这样配置：

var httpClient = &http.Client{ Timeout: 300 * time.Second, Transport: &http.Transport{ MaxIdleConns: 100, MaxIdleConnsPerHost: 20, IdleConnTimeout: 90 * time.Second, TLSHandshakeTimeout: 10 * time.Second, }, }

这里有几个细节值得说明。Timeout设为300秒，是因为大模型生成长文本时响应确实可能很慢，尤其是非流式接口，一个几十秒的响应很正常，设短了直接超时没商量。MaxIdleConnsPerHost这个参数很关键，默认值是2，如果并发量稍大，连接就不够用了，HTTP客户端会频繁新建连接，延迟明显上升。这是我在压测时踩过的坑，调大之后性能提升非常明显。

2.3 定义通用的消息结构体

为各家API写代码之前，我建议先定义一个通用的消息结构体，方便在多个接口之间复用。虽然每家的字段名有差异，但底层都是“角色 + 内容”这个基本模型。

type ChatMessage struct { Role string `json:"role"` Content string `json:"content"` }

这个结构体后面会通过不同的转换函数映射到OpenAI、Claude、Gemini各自的请求格式。统一入口的好处是，如果业务侧想记录日志或者做敏感词过滤，只要在转换前统一处理一次就够了。

3. 调用OpenAI兼容接口：从官方到各家模型服务商

3.1 调用OpenAI官方接口

OpenAI的接口格式已经成为行业事实标准，大批模型服务商都在这个协议上做兼容。我们先从标准的OpenAI Chat Completions接口开始。它的请求体核心是一个messages数组，数组里放若干条{role, content}结构，角色有system、user、assistant三种，分别用来设定系统提示词、用户输入和模型回复。

func callOpenAI(apiKey, model, prompt string) (string, error) { reqBody := map[string]interface{}{ "model": model, "messages": []ChatMessage{ {Role: "system", Content: "你是一个乐于助人的助手。"}, {Role: "user", Content: prompt}, }, "temperature": 0.7, "max_tokens": 1024, } body, err := json.Marshal(reqBody) if err != nil { return "", err } req, err := http.NewRequest("POST", "https://api.openai.com/v1/chat/completions", bytes.NewReader(body)) if err != nil { return "", err } req.Header.Set("Content-Type", "application/json") req.Header.Set("Authorization", "Bearer "+apiKey) resp, err := httpClient.Do(req) if err != nil { return "", err } defer resp.Body.Close() if resp.StatusCode != http.StatusOK { respBody, _ := io.ReadAll(resp.Body) return "", fmt.Errorf("OpenAI API error: status=%d, body=%s", resp.StatusCode, string(respBody)) } var result struct { Choices []struct { Message ChatMessage `json:"message"` } `json:"choices"` } if err := json.NewDecoder(resp.Body).Decode(&result); err != nil { return "", err } if len(result.Choices) == 0 { return "", fmt.Errorf("no choices returned") } return result.Choices[0].Message.Content, nil }

这个代码有两个地方值得强调。第一个是错误处理，HTTP状态码非200时一定要读取响应体内容并打印出来，因为大模型服务商的错误信息非常详细，比如提示你余额不足、上下文超长或者内容被安全策略拦截。第二个是响应的结构，OpenAI返回的是choices数组，里面每一项的message.content才是模型生成的内容。大多数情况下取第一个就行，但在n参数大于1时要注意choices会有多个。

3.2 一行baseURL切换多家兼容服务

OpenAI兼容接口最大的优势在于，你只要把请求的URL换掉、API Key换掉、模型名换掉，代码几乎不用改就能接入其他支持该协议的服务商。这个特性在工程上非常实用，我在团队内部就是把API和模型名做成配置项，不同环境指向不同服务商。

// 以通义千问为例 endpoint := "https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions" // 以DeepSeek为例 // endpoint := "https://api.deepseek.com/v1/chat/completions" // 以Moonshot为例 // endpoint := "https://api.moonshot.cn/v1/chat/completions"

在3.1节的代码里，只要把URL换成上面任意一个，再做以下对应修改：API Key换成该服务商控制台里创建的Key，model字段换成该服务商支持的模型名（如qwen-plus、deepseek-chat、moonshot-v1-8k）。其他代码完全不用动，这一整个生态的兼容性就是这么强。

这里我特别想说的是，如果你们团队在选型时纠结到底用哪家，我的建议是先不要花太多时间对比“谁家模型智商更高”，更多要考虑稳定性和兼容性。OpenAI兼容协议的服务商，切换成本确实低，这给业务迭代留了很大空间。

3.3 核心参数解释与生产建议

大模型API请求里那几个参数，网上文档写得都很官方，我用自己的理解翻译一下，你大概就能知道调参方向了。

temperature控制随机性，取值范围一般是0到1甚至更高。值越低回答越稳定、越保守，适合做结构化输出或者代码生成；值越高回答越发散、越有创意，适合文案创作或头脑风暴。我平时写代码调用时用0.2，让模型帮我起名字时用0.9。max_tokens控制生成的最大长度，注意这里计算的是输出token数，不是字符数。中文字符大概是1个token到2个token一个字的比例，举例来说，1024个token大约能生成500到800个汉字，要根据需求合理设置。

top_p是另一个采样参数，含义是“只从累计概率达到top_p的token里采样”，和temperature作用类似，官方建议两个不要同时调，改一个就够用了。

另外要特别提醒：不同服务商对某些参数的支持度不一样。我在接入时遇到过max_tokens被个别服务商忽略、logprobs参数不兼容的情况。如果你的代码是面向多个服务商做统一适配，我的建议是先用map[string]interface{}构造请求体，然后根据服务商类型动态增删参数，而不是写死一个固定结构。

4. 调用Anthropic Claude接口

4.1 Claude的鉴权与请求头

Claude的API和OpenAI风格差异明显，第一个区别就是鉴权方式。Claude不用Authorization头带Bearer Token，而是用两个专用请求头：x-api-key放API Key，anthropic-version放API版本号。这个版本号是必填的，不填的话接口直接报错。

请求头设置代码如下：

req.Header.Set("x-api-key", apiKey) req.Header.Set("anthropic-version", "2023-06-01") req.Header.Set("Content-Type", "application/json")

版本号我一般固定填2023-06-01，这是官方推荐的一个稳定版本。如果你有特殊需求，比如要用某个新出的beta功能，可能还需要额外加anthropic-beta请求头。我在调用Claude 3.x系列时发现，如果用了官方示例里没有的beta功能但忘了加对应头，接口会返回一个晦涩的400错误，排查起来很费劲。

4.2 构造Claude请求体

Claude请求体的结构和OpenAI差异不小。它的顶层区分了system和messages两个字段，system是系统提示词，和OpenAI里角色为system的message对应；messages数组里只有user和assistant角色，不支持嵌套system。

func callClaude(apiKey, model, systemPrompt, userPrompt string) (string, error) { reqBody := map[string]interface{}{ "model": model, "max_tokens": 1024, "system": systemPrompt, "messages": []interface{}{ map[string]interface{}{ "role": "user", "content": userPrompt, }, }, } body, err := json.Marshal(reqBody) if err != nil { return "", err } req, err := http.NewRequest("POST", "https://api.anthropic.com/v1/messages", bytes.NewReader(body)) if err != nil { return "", err } req.Header.Set("Content-Type", "application/json") req.Header.Set("x-api-key", apiKey) req.Header.Set("anthropic-version", "2023-06-01") resp, err := httpClient.Do(req) if err != nil { return "", err } defer resp.Body.Close() if resp.StatusCode != http.StatusOK { respBody, _ := io.ReadAll(resp.Body) return "", fmt.Errorf("Claude API error: status=%d, body=%s", resp.StatusCode, string(respBody)) } var result struct { Content []struct { Type string `json:"type"` Text string `json:"text"` } `json:"content"` } if err := json.NewDecoder(resp.Body).Decode(&result); err != nil { return "", err } if len(result.Content) == 0 { return "", fmt.Errorf("no content returned") } return result.Content[0].Text, nil }

Claude的响应结构也与OpenAI不同。它的content不是普通字符串，而是一个数组，数组元素有不同类型，比如text类型是正常文本，tool_use类型表示模型要调用工具。我在做Agent应用时经常要解析这个结构，如果只取content[0].Text，当模型决定调用工具时拿到的就是空字符串，这是很多初学者困惑的点。完整的处理要做类型判断，遇到tool_use时走工具调用分支。

4.3 Claude与OpenAI的关键差异

Claude接口里max_tokens是必填参数，不填字段直接报错，这一点和OpenAI不一样，OpenAI不填时会用一个默认值。另外Claude对temperature的处理也值得注意，官方文档建议大模型推理或代码生成场景用0.0到0.3，创意写作再用高一点。

Claude的响应还有一个stop_reason字段，值可能是end_turn（正常结束）、max_tokens（因为达到最大token限制而停止）、tool_use（需要调用工具）等。如果你发现生成内容不完整，就要检查stop_reason是不是max_tokens，是的话说明上一轮生成被截断了，需要增大max_tokens或者把Prompt改得精简一些。

5. 调用Google Gemini接口

5.1 Gemini的REST风格与key放置方式

Google Gemini的API和前面两家都不一样。它走的是标准的REST风格，模型方法和端点直接放在URL路径里，而且API Key不是放在Header里，而是放在URL的查询参数上。这个设计一开始我很不适应，总感觉key放在URL里不安全，但Google官方SDK就是这么干的。当然你也可以用x-goog-api-key请求头来放key，两种方式都支持。

调用gemini-1.5-flash生成文本的端点如下：

endpoint := "https://generativelanguage.googleapis.com/v1beta/models/gemini-1.5-flash:generateContent?key=" + apiKey

注意这里的URL有两个拼接点：一个是路径里的models/gemini-1.5-flash要换成具体模型名，另一个是generateContent前面有个冒号，这是Google API定义自定义方法的标准风格。如果你在写代码时一不小心把冒号漏了，或者把模型名拼错了，返回的错误信息通常是404，不会告诉你具体哪里错了，排查起来比较费眼。

5.2 构造Gemini请求体与解析响应

Gemini的请求体用的是contents数组，每项有role和parts字段。parts也是一个数组，里面放具体内容对象。这个嵌套层级比OpenAI和Claude都要深一层。

func callGemini(apiKey, model, userPrompt string) (string, error) { endpoint := "https://generativelanguage.googleapis.com/v1beta/models/" + model + ":generateContent?key=" + apiKey reqBody := map[string]interface{}{ "contents": []interface{}{ map[string]interface{}{ "role": "user", "parts": []interface{}{ map[string]interface{}{ "text": userPrompt, }, }, }, }, "generationConfig": map[string]interface{}{ "temperature": 0.7, "maxOutputTokens": 1024, }, } body, err := json.Marshal(reqBody) if err != nil { return "", err } req, err := http.NewRequest("POST", endpoint, bytes.NewReader(body)) if err != nil { return "", err } req.Header.Set("Content-Type", "application/json") resp, err := httpClient.Do(req) if err != nil { return "", err } defer resp.Body.Close() if resp.StatusCode != http.StatusOK { respBody, _ := io.ReadAll(resp.Body) return "", fmt.Errorf("Gemini API error: status=%d, body=%s", resp.StatusCode, string(respBody)) } var result struct { Candidates []struct { Content struct { Parts []struct { Text string `json:"text"` } `json:"parts"` } `json:"content"` } `json:"candidates"` } if err := json.NewDecoder(resp.Body).Decode(&result); err != nil { return "", err } if len(result.Candidates) == 0 { return "", fmt.Errorf("no candidates returned") } if len(result.Candidates[0].Content.Parts) == 0 { return "", fmt.Errorf("no parts returned") } return result.Candidates[0].Content.Parts[0].Text, nil }

Gemini响应里的candidates数组对应生成结果，每个candidate的content.parts数组里放着实际的文本内容。这里同样有个嵌套陷阱：如果模型返回了functionCall或者内联图片等内容，parts里的text字段可能为空，而functionCall字段有值。生产环境做解析时，建议对parts的每个元素做类型判断。

5.3 Gemini的generationConfig与独特功能

Gemini把生成参数放在了一个独立的generationConfig对象里，这一点和其他家也不同。里面常用的字段包括temperature、maxOutputTokens、topP、topK。其中topK是Gemini特有的采样参数，OpenAI和Claude都没有，它表示只从概率最高的K个token里采样，控制生成多样性时可以用到。

Gemini还支持系统指令，在generateContent请求里加一个systemInstruction字段。这个字段的结构和contents类似，也是parts数组。我在做聊天机器人时喜欢用这个功能，因为相比把系统提示词塞进用户消息里，独立字段语义更清晰，也方便调试。

6. 流式输出：让大模型一个字一个字蹦出来

6.1 为什么需要流式、SSE协议基础

用非流式接口生成一篇长文，用户可能要等十几秒才能看到结果，体验很差。解决方式是使用流式接口，让模型每生成一个片段就通过SSE（Server-Sent Events）推送到客户端，客户端收到一个片段就刷新一次页面或消息框。现在主流聊天应用都是这个体验，GPT网页端接了个HTTP流，响应还没结束就已经开始打字了。

SSE协议的基础很简单：响应体的Content-Type是text/event-stream，每行以data:开头，后面跟着JSON数据。不同事件之间用空行分隔，流结束时有一个专用的结束标记。实现方式用bufio.Reader逐行读取即可。

提示：一定要先看响应头里的Content-Type，很多新手在流式接口返回后直接用json.Decoder解析整个body，结果发现响应是text/event-stream格式，解析器直接报错。

6.2 OpenAI流式解析实战

OpenAI的流式接口在请求体里加个"stream": true就行，其他字段基本不变。响应流里，每一行data:后面是一个JSON对象，里面的choices[0].delta.content字段就是增量文本。把所有增量拼接起来，就是完整的回复。

func callOpenAIStream(apiKey, model, prompt string, onDelta func(string)) error { reqBody := map[string]interface{}{ "model": model, "messages": []ChatMessage{{Role: "user", Content: prompt}}, "stream": true, } body, _ := json.Marshal(reqBody) req, _ := http.NewRequest("POST", "https://api.openai.com/v1/chat/completions", bytes.NewReader(body)) req.Header.Set("Content-Type", "application/json") req.Header.Set("Authorization", "Bearer "+apiKey) resp, err := httpClient.Do(req) if err != nil { return err } defer resp.Body.Close() reader := bufio.NewReader(resp.Body) for { line, err := reader.ReadString('\n') if err != nil { if err == io.EOF { return nil } return err } line = strings.TrimSpace(line) if !strings.HasPrefix(line, "data:") { continue } data := strings.TrimSpace(strings.TrimPrefix(line, "data:")) if data == "[DONE]" { return nil } var chunk struct { Choices []struct { Delta struct { Content string `json:"content"` } `json:"delta"` } `json:"choices"` } if err := json.Unmarshal([]byte(data), &chunk); err != nil { continue } if len(chunk.Choices) > 0 { onDelta(chunk.Choices[0].Delta.Content) } } }

这里有几个隐藏细节。ReadString按换行符读，每行是一个事件；字符串处理时要去掉data:前缀；流结束标志[DONE]是一个单独的字符串，不是JSON，所以要先判断再解析。还有，解析JSON失败时不能直接返回错误，因为网络抖动可能导致一个不完整的事件，稳妥做法是跳过当前解析，继续读下一行。

6.3 Claude与Gemini的流式注意事项

Claude的流式接口也是加"stream": true，但它的SSE事件分成了多种类型。常见的有message_start、content_block_delta、message_delta、message_stop。其中content_block_delta事件里的delta.text字段才是增量文本。所以解析Claude流时，必须对event:行做判断，只处理content_block_delta类型，否则你会把一堆元数据一起当作正文输出。

Gemini的流式端点是streamGenerateContent?alt=sse&key=...。注意要带上alt=sse参数，否则即使你发起的是流式请求，返回的也可能是普通JSON而不是SSE流。Gemini流里的data:字段结构与非流式响应基本相同，也是candidates[0].content.parts[0].text，所以解析逻辑可以直接复用。

在生产环境我一般会封装一个StreamReader接口，统一OpenAI和Claude、Gemini的增量回调，由上层业务只接收content string，这样切换模型时调用方代码不用改。

7. 手写HTTP还是用SDK：效率与灵活的取舍

7.1 各家官方SDK的体验

OpenAI官方提供了Go SDK，包名是github.com/openai/openai-go，对标准接口的封装相当完整，支持流式、支持工具调用、支持多模态，代码提示也做得不错。Anthropic也有官方Go SDK，Gemini也在不断更新他的Go客户端。

用SDK最大的好处是省事，几行代码就能调起来，不用关心HTTP细节。而且官方SDK通常会处理重试、错误解析等事情。如果项目规模不大、只接一家模型、也不打算切换服务商，用官方SDK是非常高效的选择。

7.2 什么时候建议手写HTTP

但如果你和我一样，在做一个需要对接多个模型基座的统一网关，我强烈建议至少底层调用部分自己写HTTP。原因有三点。第一，官方SDK形态各异，OpenAI的SDK和Claude的SDK接口风格完全不同，混在一起抽象成本反而更高；第二，SDK版本更新频繁，接口变动可能连编译都过不去，维护成本高；第三，出了问题不好排查，SDK把日志吞了，你根本不知道原始HTTP请求长什么样。

我自己的实践是：底层只有一层通用的HTTPClient和StreamReader接口，各家适配层维护各自的请求构造和响应解析。这样换模型、加服务商都只是改配置加一个适配文件，而且每个环节都能打印日志，排查线上问题特别快。

7.3 中间网关方案：one-api风格

如果你对接的模型服务商特别多，比如既要OpenAI又要Claude还得兼容国内多家厂商，还有一种路线值得考虑——直接部署一个模型网关服务，比如类似one-api这类开源项目，把各家API统一成OpenAI兼容格式。然后在Go代码里只面向一个OpenAI兼容端点请求。

这个方案在团队内部特别实用，因为最终业务代码只需要维护一套模型调用逻辑，不同模型之间的调度、鉴权、限流全交给网关处理。我见过很多团队把网关部署在内部，统一管理所有模型的Key和配额，权限控制也方便。不过网关本身引入了额外组件，部署和运维成本要自己权衡。

8. 常见问题与排查技巧实录

8.1 认证失败与状态码速查

大模型接口调不通，一半以上是认证问题。我做过一个速查表，遇到错误码直接对照定位，能省不少排查时间。

8.2 超时与重试策略

大模型接口的响应时间波动很大，正常时候一两秒返回，高峰期可能十几秒甚至几十秒。如果网络再抖动一下，客户端就很容易超时。生产环境我常用的策略是：首次请求超时设置30秒，如果是流式请求理论上是长连接，整体不设超时，但通过http.ResponseController做空闲超时控制；遇到429或500类错误用指数退避算法重试，退避间隔从1秒开始，成倍增长，最多重试3次。

func retryWithBackoff(attempts int, fn func() error) error { delay := time.Second for i := 0; i < attempts; i++ { if err := fn(); err == nil { return nil } time.Sleep(delay) delay *= 2 } return fmt.Errorf("all attempts failed") }

这里特别提醒一句：重试逻辑千万不要做成“不管什么错误都立刻重发”，因为如果错误是请求参数本身有问题（400），重试一百次也是同样的结果。正确做法是只对429、5xx这类暂时性错误重试，4xx错误直接抛给上层处理。

8.3 响应解析失败与结构变化

接入不同基座时，“解析失败”是我见过最多的坑。明明API返回200了，但JSON解析出来的内容为空。遇到这个问题，我建议先在Postman或者调试工具里把完整响应打出来看一遍。大模型服务的响应体里经常会有额外的元信息字段，不同版本请求头也会造成字段结构调整，比如OpenAI的content在工具调用场景下可能变成空，但tool_calls字段不为空。

我的做法是在适配层加一个响应原始内容日志，任何解析异常都把原始body记录到日志文件。这样线上问题可以直接从日志里看到模型到底返回了什么，而不是只能拿到一个“解析失败”的笼统错误。排查几次你就会发现，很多解析失败其实都是用例没有覆盖到的结构，类型判断写好就迎刃而解。

8.4 上下文长度与Token限制

对话场景里经常出现“聊着聊着就报错”的情况，提示内容太长超出模型上下文窗口。这个错误几乎每家模型都有，只是报错信息不同，OpenAI给maximum context length exceeded，Claude给prompt is too long，Gemini返回400。这背后是模型的最大输入+输出token总和有上限。

处理方案没有太多花哨的，就是做消息裁剪。我常用的策略是：用滑动窗口保留最近N轮对话，超出部分丢弃；或者把历史消息做摘要，用一个summary系统消息替代早期对话内容。具体数值取决于模型上下文窗口大小，比如8K上下文的模型，我一般只保留最近十轮左右对话，再算上系统提示词和当前输入，留一半空间给输出。

8.5 并发与连接池调优

当你的服务开始同时处理多个用户请求时，HTTP客户端的连接池配置就成了隐藏瓶颈。默认MaxIdleConnsPerHost只有2，意味着同一时间同一主机的活动连接超过2个就要不断新建TCP连接，延迟上升明显。我在2.2节中给出的配置就专门调大了这个值。

另外，大模型服务商对单账户的并发有严格限制，触发限流是家常便饭。应对方案有两个思路：一是应用层加信号量控制并发数，避免突发流量把配额打满；二是把不同业务线拆分成多个API Key，分散限额压力。我遇到过的最极端情况是某个定时任务一次性发起大量并发请求，直接把账户限流打满，其他业务的调用全部失败，后面就统一加了并发闸门。

写在最后：一点个人经验

这一套代码写下来，最大的感受就是：大模型调用没有想象中那么神秘，本质上就是一个带流式协议的HTTP JSON接口。真正花时间的往往不是“调通”，而是把调通的代码做得足够健壮，能应对超时、限流、模型参数差异、响应结构变化这些杂七杂八的事。我个人的习惯是，无论用哪家SDK，都会在最底层保留一个可以打印原始请求和响应日志的开关。遇到问题先看原始报文，再去查文档，十有八九能直接定位。另外，新接入一个模型基座时，不要一上来就做复杂功能，先写好最基础的“发一条消息拿回文本”再往上面叠流式、工具调用，这样排查起来链路短、出错好定位。希望这篇实战记录能帮你在Go里少踩几个坑，把更多精力放到业务本身去。