先用 runtime/pprof 抓取生产流量下的 CPU profile，重点分析 top -cum 中 mallocgc、Mutex.Lock、net.conn.Read 异常占比，再检查 HTTP 超时配置、gRPC 连接复用与流控、database/sql 连接池及 context 透传。
Go 微服务 CPU 占用高但 QPS 上不去，先看 runtime/pprof 是否漏掉关键采样
很多团队一上来就调 GOMAXPROCS 或加机器，其实 70% 的 CPU 瓶颈来自未识别的锁竞争或频繁堆分配。必须用 pprof 实际抓取生产流量下的 profile，而不是本地压测结果。
- 启动时注册 HTTP pprof handler：
import _ "net/http/pprof" go func() { http.ListenAndServe("localhost:6060", nil) }() - 采集 30 秒 CPU profile：
curl -o cpu.pprof "http://localhost:6060/debug/pprof/profile?seconds=30" - 重点看
top -cum输出中是否出现大量runtime.mallocgc、sync.(*Mutex).Lock或net.(*conn).Read占比异常高 - 避免只看
top——top -cum才能暴露调用链上层的“真凶”，比如某个 HTTP middleware 里反复json.Unmarshal导致 GC 压力
HTTP 服务吞吐卡在 1k QPS 左右，检查 http.Server 的超时与连接复用配置
默认 http.Server 配置在微服务间高频调用下极易成为瓶颈，尤其当上游没设 Timeout、下游又没关 Keep-Alive 时，连接堆积+TIME_WAIT 暴涨是常态。
- 必须显式设置三类超时：
ReadTimeout、WriteTimeout、IdleTimeout，例如：srv := &http.Server{ Addr: ":8080", ReadTimeout: 5 * time.Second, WriteTimeout: 10 * time.Second, IdleTimeout: 30 * time.Second, } - 客户端侧禁用默认
http.DefaultClient，自定义http.Client并复用http.Transport：client := &http.Client{ Transport: &http.Transport{ MaxIdleConns: 100, MaxIdleConnsPerHost: 100, IdleConnTimeout: 30 * time.Second, }, } - 别信 “Golang HTTP 性能无敌” —— 如果每个请求都新建
http.Client，连接池失效，TIME_WAIT数会指数级上升
gRPC 服务延迟毛刺明显，确认 grpc.Dial 是否复用及流控参数是否合理
gRPC 默认不启用流控，小包高频调用下容易触发内核缓冲区满、丢包重传，表现为 P99 延迟突增，但平均值看起来正常。
-
grpc.Dial必须全局复用，禁止每次请求都Dial—— 否则连接数爆炸且 TLS 握手开销不可控 - 服务端需设置
grpc.MaxConcurrentStreams（默认 100），若单实例承载 200+ 并发流，建议调高到 500–1000 - 客户端加
grpc.WithBlock()+grpc.FailOnNonTempDialError(true)避免首次调用失败静默降级 - 若使用
grpc-go v1.60+，启用grpc.WithKeepaliveParams减少空闲连接断连重连抖动：keepaliveParams := keepalive.ClientParameters{ Time: 10 * time.Second, Timeout: 3 * time.Second, PermitWithoutStream: true, }
数据库访问慢但 SQL 本身很快，排查 database/sql 连接池与上下文超时传递
Go 的 database/sql 连接池不是“越大会越好”，而要匹配后端 DB 的最大连接数和业务并发模型；更隐蔽的问题是 context 超时没透传到 QueryContext，导致慢查询阻塞整个 goroutine。
立即学习“go语言免费学习笔记（深入）”；
- 设置连接池参数前，先查 DB 允许的最大连接数（如 MySQL
max_connections），然后按实例数分摊：db.SetMaxOpenConns(20) db.SetMaxIdleConns(10) db.SetConnMaxLifetime(1 * time.Hour)
- 所有 DB 调用必须用
ctx版本函数：db.QueryRowContext(ctx, ...)，否则context.WithTimeout对 DB 操作完全无效 - 警惕 ORM（如 GORM）自动注入的隐式事务 —— 若没手动
Rollback或Commit，连接会一直被占用直到 GC 回收 - 用
db.Stats()定期打印OpenConnections和InUse，若InUse == MaxOpen持续存在，说明有连接泄漏
真实性能瓶颈往往藏在 “大家都这么写” 的默认配置里。pprof 不只是看火焰图，更是验证你对调用路径的理解是否准确；超时不是加个数字，而是明确每一层谁该负责中断、谁该负责兜底。调优不是改参数，是让每条 goroutine 的生命周期、每个连接的复用边界、每次内存分配的归属都清晰可追溯。
