Go API响应慢主因是超时未分层、连接池错配、JSON解析重、gzip未启用；需分设DialContextTimeout（2s）、TLSHandshakeTimeout（3s）、ResponseHeaderTimeout（5s），依目标服务调优MaxIdleConnsPerHost，改用jsoniter并启用gzip.BestSpeed压缩。
Go 写的 API 接口响应慢，八成不是语言问题，而是请求路径上某处卡住了——比如没分层设超时、JSON 解析太重、连接池配错，或者压根没开 gzip。先定位瓶颈，再动代码。
HTTP 客户端超时必须分层设置
只设 http.Client.Timeout 是最常见错误。它会把建连、TLS 握手、header 到达、body 读取全捆在一起，一个环节卡住就拖满整个超时时间。
-
Transport.DialContextTimeout单独控制 DNS + TCP 建连，建议设2s -
Transport.TLSHandshakeTimeout针对证书协商，老旧服务建议3s -
Transport.ResponseHeaderTimeout约束 header 返回，防后端挂住不发头，5s较稳 -
Timeout仅作兜底（如10s），用于防雪崩，不是主逻辑超时依据
不分层，你就没法区分是网络问题还是业务慢，日志里全是 context deadline exceeded，但不知道卡在哪一环。
连接池参数得按目标服务调，不能通用一套
MaxIdleConnsPerHost 设太高，可能直接打爆下游连接数限制；设太低，又频繁重建 TLS 连接，白白增加 RTT。
立即学习“go语言免费学习笔记（深入）”；
- 对接云厂商 API（AWS/Aliyun）：keep-alive timeout 通常 60–300s，
MaxIdleConnsPerHost=20–50较安全 - 对接 PHP 或老旧 Java 服务：keep-alive 往往不可靠，
MaxIdleConnsPerHost=2–5反而更省资源 - 务必设
Transport.IdleConnTimeout = 0，让对方决定连接生命周期，别自己关掉还留着 stale conn
曾有个政务系统接口，对方 nginx keepalive_timeout 是 5s，但我们设了 IdleConnTimeout=30s，结果连接池里一堆失效连接，大量请求 fallback 到新建连接。
序列化和压缩不能靠默认配置
标准库 encoding/json 在大数据量下明显拖后腿，gzip 不开等于裸传 JSON 文本，尤其返回列表时体积翻倍。
- 用
jsoniter.ConfigCompatibleWithStandardLibrary替代encoding/json，序列化快 30%+，且完全兼容 - 启用 gzip 中间件（如
gin-contrib/gzip），但只对text/*和application/json压缩，跳过图片、PDF 等已压缩类型 - 压缩级别选
gzip.BestSpeed，别用BestCompression，CPU 换来的那点体积节省在现代带宽下不值当
结构体字段多但实际只用几个？加 json:"-" 或拆专用响应 struct，避免无意义拷贝和序列化开销。
pprof 不只是“看看”，得跑起来才有效
没开 pprof，所有优化都是猜。光看 QPS 和平均延迟没用，P99 才暴露真实毛刺。
- 启动时加
_ "net/http/pprof"，另起 goroutine 跑http.ListenAndServe("localhost:6060", nil) - 压测时抓
curl http://localhost:6060/debug/pprof/profile?seconds=30得 CPU profile，用go tool pprof查热点函数 - 内存暴涨？跑
curl http://localhost:6060/debug/pprof/heap看谁在疯狂make([]byte)
很多团队开了 pprof 却从不访问那个端口，或者只在本地跑一下就以为“做过分析”了——线上没压测数据，profile 就是废图。
