答案：需复用http.Client并显式配置Transport参数、用协程池控制并发数、全程传递context超时、预分配JSON结构体、实施带jitter的指数退避重试。具体包括设置MaxIdleConns/MaxIdleConnsPerHost为200、IdleConnTimeout为30s，用semaphore或buffered channel限流至50，并通过context.WithTimeout创建请求上下文、json.Unmarshal前初始化struct或使用json.RawMessage，重试时采用base×2^n+随机jitter策略且仅针对网络错误和5xx响应。
goroutine 无节制启动导致连接耗尽
直接在 HTTP handler 里写 go func() {...}() 处理外部 API 调用，看似并发提升，实则极易触发 net/http.DefaultTransport 的连接池上限（默认 100 连接/每 host），大量 goroutine 卡在 RoundTrip 等待空闲连接，最终请求超时或堆积。
真正可行的做法是：复用 http.Client 并显式配置 Transport，同时用协程池控制并发数：
- 设置
MaxIdleConns和MaxIdleConnsPerHost到合理值（如 200/200），避免连接复用不足 - 设
IdleConnTimeout（建议 30s）防止长连接泄漏 - 用
golang.org/x/sync/semaphore或带缓冲 channel 控制同一时刻最多 N 个外部调用，比如限制为 50 - 绝不复用未配置的默认 client，尤其在微服务中多个模块共用时
context.WithTimeout 未穿透到下游 HTTP 请求
常见错误是只在 handler 层加 context.WithTimeout，但没传给 http.NewRequestWithContext，导致外部 API 即使响应慢、卡死，当前 goroutine 也无法被 cancel，进而拖垮整个服务。
必须全程传递 context：
立即学习“go语言免费学习笔记（深入）”；
- handler 入口创建带超时的 context：
ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second) - 构造 request 时使用：
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil) - 调用 client.Do(req) 后，检查
err是否为context.DeadlineExceeded或context.Canceled - 务必调用
cancel()—— 即使请求成功也要释放资源，否则可能引发 context 泄漏
JSON 反序列化未预分配结构体字段导致 GC 压力飙升
高并发下调用外部 API 返回大量 JSON，若用 json.Unmarshal([]byte, &v) 解析到临时 map 或未初始化的 struct，会频繁触发堆分配和 GC，实测 QPS 上万时 GC 频次可翻倍。
优化关键点：
- 定义明确 struct，字段类型尽量具体（避免全用
interface{}） - 对高频接口，提前初始化 struct 实例并复用（配合
sync.Pool） - 若响应结构动态，用
json.RawMessage延迟解析，只解需要的字段 - 禁用反射式解码库（如某些泛型 JSON 库），标准库
json在已知 schema 下性能更稳
重试逻辑没做指数退避 + jitter，反而加剧下游雪崩
简单 for 循环 + time.Sleep(100 * time.Millisecond) 重试，会在故障期间对下游 API 发起密集、同步的重试风暴，把原本 10% 的失败率放大成 90% 不可用。
生产级重试必须满足三点：
- 使用指数退避：第 n 次重试延迟为
base * 2^n（base 建议 100ms） - 加入 jitter（随机偏移，如 ±25%），打散重试时间点
- 设置最大重试次数（通常 ≤ 3），并结合 circuit breaker（如
hystrix-go）快速熔断 - 重试前检查 error 类型——仅对网络错误、5xx 重试，4xx（如 404、400）应立即失败
真实场景里最易被忽略的不是并发数，而是每个外部调用背后那层隐式依赖：DNS 解析超时、TLS 握手抖动、对方服务限流返回 429 却没被识别。这些不会出现在 goroutine profile 里，但会持续抬高 P99 延迟。
