Go微服务性能瓶颈90%源于通信、并发和资源管理不当；换gRPC、加连接池、控goroutine数可降P99延迟30%以上，关键在HTTP/2复用、Protobuf编码、合理配置连接池与context超时。
Go 微服务性能上不去，90% 不是语言问题，而是通信、并发和资源管理没调对。直接换 gRPC、加连接池、控 goroutine 数量，通常就能把 P99 延迟压下去 30% 以上。
用 gRPC 替掉 http.Client + encoding/json
HTTP/1.1 + JSON 是开发最顺的组合，但也是性能杀手：每次请求都要建连、解析字符串、反射赋值，CPU 和带宽都浪费在“可读性”上。
- gRPC 默认走 HTTP/2，复用单 TCP 连接，支持多路复用——10 个并发调用不产生 10 次握手
- Protobuf 编码体积比等效 JSON 小 60%+，
Unmarshal耗时通常只有json.Unmarshal的 1/5 - 别手写
.proto；用protoc-gen-go生成强类型代码，避免运行时字段拼错或类型转换 panic - 注意：gRPC 默认不压缩，大响应体（如用户列表）要手动开启
grpc.WithCompressor(gzip.NewCompressor())
连接池不是“开了就行”，关键看 MaxIdleConnsPerHost 和 IdleConnTimeout
很多人配了 http.Transport 就以为万事大吉，结果压测时发现连接数暴涨、TIME_WAIT 堆积——其实是参数没对齐下游服务的承载能力。
-
MaxIdleConnsPerHost建议设为下游服务单实例能承受的并发连接数（比如 20～50），不是越大越好 -
IdleConnTimeout推荐 30s，太短导致频繁重连，太长（如 5m）会让空闲连接占着端口不放 - gRPC 客户端默认复用连接，但如果你用
grpc.Dial频繁新建 client（比如 per-request），等于绕过连接池——必须全局复用一个*grpc.ClientConn - 漏掉
KeepAlive配置？加上grpc.WithKeepaliveParams(keepalive.ClientParameters{Time: 30 * time.Second})，防 NAT 超时断连
别乱起 goroutine，用 errgroup.Group + context.WithTimeout 控制生命周期
微服务里最常见“性能假象”：QPS 看似很高，但大量 goroutine 卡在慢下游上，内存涨、延迟飘、重启卡死——本质是没做超时和取消。
立即学习“go语言免费学习笔记（深入）”；
- 永远别写
go doSomething()这种裸启动；用errgroup.Group统一等待，并自动传播 cancel - 每个外部调用（DB、RPC、HTTP）必须套
ctx, cancel := context.WithTimeout(ctx, 800*time.Millisecond)，超时立刻释放资源 - goroutine 数量失控？用
semaphore.Weighted限流，比如限制最多 5 个并发 DB 查询：sem := semaphore.NewWeighted(5)，sem.Acquire(ctx, 1)再执行 - 别忘了 defer
cancel()，否则 context 泄漏，goroutine 永远不会退出
sync.Pool 不是万能缓存，只适合“高频创建 + 短期存活”的对象
看到别人用 sync.Pool 就跟着抄？容易适得其反：Pool 本身有锁开销，对象复用不当还会引发数据污染或 panic。
- 适用场景：临时
[]byte、bytes.Buffer、Protobuf message 实例（非指针共享）、JSON 解析器——生命周期在单次请求内 - 禁止放入含外部引用的对象（比如带
http.Request字段的 struct），归还后可能被其他 goroutine 误读旧数据 - 初始化
New函数必须返回干净实例：New: func() interface{} { return &MyStruct{} }，不能返回全局变量或未重置对象 - 实测：在日志序列化环节用 Pool 复用
bytes.Buffer，GC 压力下降 40%，但若错误地复用http.Header，会导致 header 键值串扰
真正卡住性能的，往往不是某一行代码，而是连接复用策略和上下文超时的配合是否严密——比如 gRPC 客户端开了连接池，但每个调用没传 context，或者传了却没设 timeout，那连接再省也白搭。
