谭康熹做Go后端这几年，我有个很深的体会：HTTP服务的性能问题，很少在一开始就暴露在CPU或者内存指标上，它往往先表现为接口变慢、连接堆积、上游超时，最后才以一次502或者504的形式拍在监控大屏上。这篇东西想聊的，就是Go语言HTTP服务从“能跑”到“扛得住”之间，那些真正值得动手优化的点。它不是给零基础看的框架教程，而是面向已经在用Go写接口、又觉得当前服务差点意思的开发者——你不需要换框架、不需要上容器编排，就能在连接层、应用层、上游调用层把服务撸顺。
我把这几年的优化经验拆成了六块：先聊怎么定位瓶颈，再聊连接层、应用层、上游依赖层的优化手段，中间穿插一个完整的压测案例，最后整理一份线上排查速查表。每块都有可复现的参数和代码片段，拿过去就能在自己的服务上试。
1. 先搞定性能基线：不知道瓶颈在哪，优化就是空谈
1.1 一次典型的“慢接口”复盘
先讲个真实经历。有次线上一个下单接口在晚高峰从平均50ms涨到1.5秒，监控里CPU不高、内存平稳、数据库慢查询日志也没异常。当时第一反应是代码出问题了，于是盯着链路追踪看了半天，最后发现根源不在业务代码，而是服务发往下游订单中心的一个HTTP客户端连接池被占满了。下游接口本身只要20ms，但有个调用方把连接全占着不放，排队时间活生生把P99拖到了2秒以上。
这个案例很典型。很多人一听到“HTTP服务优化”，第一反应是调框架参数、换JSON库，但大部分性能问题压根不在单次请求的处理速度上，而在资源争抢和等待上。所以优化的第一步，不是动手改代码，而是先建立一套能看清服务健康状况的指标体系。
1.2 核心指标与观测手段
我常用的四个维度是延迟、吞吐、错误率和饱和度：
- 延迟。不要只看平均值，平均值会掩盖长尾问题。重点盯P50、P95、P99，P99能反映最差一波用户体验。Go里用HdrHistogram或者简单的百分位统计都能做，线上至少保留P95和P99两个分位数。
- 吞吐。每秒能处理多少请求，也就是常说的QPS。但这个数字要结合延迟看，只谈QPS不谈延迟没有意义。同样一台机器，2万QPS的P99是200ms，和1万QPS的P99是50ms，后者往往才是健康的。
- 错误率。5xx比例、超时比例、客户端断连比例，这类指标比延迟更先暴露问题。一般我会在网关层和每个服务内部都埋上状态码计数器。
- 饱和度。连接数、goroutine数量、GC耗时、线程池排队长度。这类指标反映的是系统还有多少余量，我见过太多服务CPU才30%就大面积超时，原因就是goroutine堆积在等锁或者等网络IO。
观测手段上，Go自带的东西基本够用。标准库net/http/pprof只要import一下，再在main里挂个端口，就能拿到CPU、内存、goroutine的profile。线上我会额外暴露/debug/vars，配合expvar包把请求数、耗时、错误数导出来，Prometheus抓走就能画图。再往上就是链路追踪了，这个看团队基础设施，没有的话至少要在日志里带上request_id，否则出问题连请求从哪个节点出去的都查不到。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 连接层优化：http.Server的几个参数值回票
2.1 四个超时参数的正确姿势
Go标准库的http.Server有四个容易被忽略的超时参数，很多人直接留零值，等于没设。这四个是ReadTimeout、ReadHeaderTimeout、WriteTimeout和IdleTimeout。
我把它们的分工用一句话总结：ReadTimeout管请求体读多久，ReadHeaderTimeout管请求头读多久，WriteTimeout管响应写多久，IdleTimeout管一个连接空闲多久后关闭。很多线上问题就是这四个参数没设导致的。比如WriteTimeout不设，某个接口响应特别慢时，TCP连接会一直挂着不释放；IdleTimeout不设，连接池里的长连接永远不会被回收，极端情况下文件描述符会被占满。
我的推荐配置长这样：
go复制server := &http.Server{
Addr: ":8080",
Handler: router,
ReadTimeout: 5 * time.Second,
ReadHeaderTimeout: 3 * time.Second,
WriteTimeout: 10 * time.Second,
IdleTimeout: 60 * time.Second,
MaxHeaderBytes: 1 << 20,
}
注意ReadTimeout要大于等于ReadHeaderTimeout，否则头部超时还没触发，读超时先触发了。WriteTimeout的值要根据最慢接口的合理耗时定，不要拍脑袋。如果你有个上传接口需要读大文件，ReadTimeout就得给足，但可以让ReadHeaderTimeout保持很短，避免头部慢速攻击拖垮服务。
2.2 Keep-Alive与连接复用的取舍
HTTP/1.1默认开启Keep-Alive，这个一定要保留。短连接模式下每个请求都要重新走TCP三次握手，高并发时握手开销会吃掉大量CPU，而且会积压大量TIME_WAIT连接。Go的http.Server在Keep-Alive上是默认打开的，但有个细节要注意——SetKeepAlivesEnabled(false)会被某些框架或者中间件误关，压测时看不出来，线上流量