Go微服务吞吐量瓶颈八成源于并发模型与业务节奏错配：batcher超时设置不当引发延迟抖动，goroutine池大小未匹配CPU核心数导致调度开销激增，RPC并发过高触发锁争用和GC飙升，HTTP客户端未复用连接耗尽文件描述符。
Go 微服务吞吐量上不去，八成不是 CPU 或带宽瓶颈，而是并发模型没对齐业务节奏——比如用 goroutine 池硬扛高频小请求，却忘了批处理能省掉 70% 的序列化开销；又或者 RPC 并发数设得过高，反而触发锁争用和 GC 飙升。
batcher.New 超时设置不当导致延迟抖动
go-resiliency 的 batcher.New 第一个参数是超时时间，它直接决定批次大小和端到端延迟。设成 100*time.Millisecond 在日志上报场景没问题，但用在实时风控接口里，P95 延迟会突增 80ms。
- 高频低延迟接口（如鉴权、限流）：超时必须 ≤
20*time.Millisecond，否则用户感知卡顿 - 后台任务（如埋点聚合、邮件队列）：可放宽至
200*time.Millisecond，但需配合batcher.Prefilter过滤无效请求，避免空批次浪费 - 别把超时和缓冲区大小混为一谈：
batcher.New的第二个参数是处理函数，第三个才是可选的缓冲通道容量；超时触发强制 flush，缓冲区满才触发提前 flush
goroutine 池大小与 CPU 核心数不匹配
很多项目盲目设 semaphore := make(chan struct{}, 100) 控制并发，结果在 4 核机器上跑出大量 Goroutine 等待调度，pprof 显示 runtime.schedule 占 CPU 15% 以上。
- 池大小建议 =
runtime.NumCPU() * 2起步，再根据实际监控调整；超过runtime.NumCPU() * 6后，调度器开销增长非线性 - 不要复用同一池处理 I/O 密集型（如 HTTP 调用）和 CPU 密集型（如 JSON 解析）任务——前者需要更多 goroutine 等待网络响应，后者会阻塞 M
- 用
sync.Pool缓存池中 worker 的临时对象（如bytes.Buffer），避免每次任务都触发 GC
RPC 并发数配置引发锁竞争
mqant 或自研框架里常见的 ConcurrentTasks 配置项，设太高会导致 sync.Mutex 在连接池或上下文管理器上成为热点。
立即学习“go语言免费学习笔记（深入）”；
- 先查
rpc_server.go中executing字段的监控值：持续 > 80% 就说明并发数已溢出，不是加资源而是要拆接口 - 对强依赖下游的服务调用，用
context.WithTimeout+time.AfterFunc主动熔断，比等 RPC 层超时更可控 - 避免在 RPC handler 里直接调用
log.Printf—— 同步写文件会锁住整个 logger 实例；改用框架提供的异步日志（如 mqant 的Async()）
HTTP 客户端未复用连接拖慢吞吐
每个请求都新建 http.Client，不仅耗 CPU，还会快速占满文件描述符，netstat -an | grep :80 | wc -l 轻松破千。
- 全局复用一个
http.Client，并显式设置Transport：MaxIdleConnsPerHost: 100、IdleConnTimeout: 30*time.Second - 别信默认的
http.DefaultClient—— 它的Transport是共享的，但你无法控制其参数，且可能被其他包污染 - 对内网服务调用，关闭 TLS 验证（
InsecureSkipVerify: true）并启用 HTTP/2，实测 QPS 提升 40%+；对外网必须保留验证
真正卡吞吐的地方，往往藏在「看起来很合理」的配置里：比如 batcher 超时设成 50ms，但下游平均响应 45ms，结果一半请求都在等那最后 5ms 强制 flush；又比如 goroutine 池设了 200，可 P99 GC STW 时间已经到 12ms——这时候调小池子比加机器管用。
