Go微服务吞吐量上不去的主因是Goroutine泄漏、内存分配失控、连接池耗尽或超时配置缺失；需控制并发数、复用资源、全链路设超时，并通过pprof定位goroutine阻塞、内存分配和锁竞争热点。
Go 微服务吞吐量上不去，大概率不是 CPU 或带宽瓶颈，而是 Goroutine 泄漏、内存分配失控、连接池耗尽或超时配置缺失——这些问题在压测初期就暴露，但常被误判为“并发不够”。
控制 goroutine 并发数量，别依赖“它很轻”
每请求启一个 goroutine 是最常见吞吐崩盘起点。runtime.NumGoroutine() 突增至数万时，调度器已过载，P99 延迟飙升不是因为逻辑慢，而是 goroutine 在排队等 M。
- 用
ants.NewPool(200)替代裸go handle()，池大小从runtime.NumCPU() * 3开始压测，观察 P99 和 GC pause 是否同步拐点 - HTTP handler 中禁止直接调用阻塞操作（如未设 context 超时的
db.QueryRow()），所有 I/O 必须带ctx.WithTimeout() - 避免在 goroutine 内部启动新 goroutine 处理子任务（如循环里嵌套
go sendToKafka()），改用 worker 池统一承接
复用连接与缓冲，别让 syscall 成瓶颈
net/http 默认的 MaxIdleConns=100 在高 QPS 场景下极易打满，表现是大量 http: server gave HTTP response to HTTPS client 错误——实际是连接池拒绝新请求，客户端重试导致雪崩。
- 服务端：显式设置
http.Server.IdleTimeout = 30 * time.Second，并用ConnState回调统计活跃连接数，防止 fd 耗尽 - 客户端：复用单例
http.Client，Transport 配置MaxIdleConns=200、MaxIdleConnsPerHost=50、IdleConnTimeout=90*time.Second - 对小包协议（如 gRPC 流、自定义 TCP 协议），在
net.Conn上套bufio.NewReaderSize(conn, 8192)，可降低 60%+ 的read()系统调用频次
减少堆分配，让 GC 不拖后腿
pprof 查 runtime.mallocgc 占比 >35%，基本可断定吞吐卡在 GC。高频分配的小对象（如 http.Header、json.RawMessage）会快速填满 mspan，触发 STW。
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Pool缓存临时 buffer：定义var jsonBufferPool = sync.Pool{New: func() interface{} { return new(bytes.Buffer) }}，handler 中b := jsonBufferPool.Get().(*bytes.Buffer); b.Reset() - JSON 序列化优先用
json.NewEncoder(w).Encode(data)直接流式写入，避免json.Marshal()产生中间 []byte - 字符串拼接禁用
+，循环中必须用strings.Builder；结构体字段若只读且固定长度，考虑用[32]byte替代string避免逃逸
监控真实瓶颈，别优化错地方
盲目调大 GOMAXPROCS 或换 fasthttp，90% 的情况只是掩盖了 goroutine 泄漏或锁争用。真正有效的优化，永远始于 /debug/pprof/ 的三张图。
- 查阻塞：访问
/debug/pprof/goroutine?debug=2，过滤出长期处于select或chan receive的 goroutine，定位 channel 未关闭或无消费者 - 查分配热点：
go tool pprof http://localhost:6060/debug/pprof/heap，聚焦 topN 中makeSlice、newobject调用栈 - 查锁竞争：
go tool pprof http://localhost:6060/debug/pprof/mutex，看sync.(*Mutex).Lock是否集中在某段代码（如全局 map 未分片）
最容易被忽略的是：超时配置必须覆盖整个请求生命周期——ReadTimeout 只管 header，ReadHeaderTimeout 才防大 body 卡住，Context 超时要贯穿 DB、Redis、下游 RPC 全链路。少一环，压测时就可能看到突增的 goroutine 和暴涨的 GC 次数。
