应优先排查跨服务调用、HTTP客户端超时配置缺失及goroutine阻塞，而非业务逻辑；通过/debug/pprof/goroutine?debug=2查堆积状态，显式设置Transport各阶段超时，并结合链路追踪定位Span间Gap与下游慢调用。
Go微服务响应延迟高，不能只盯着单个接口耗时——90%的问题出在跨服务调用、HTTP客户端配置或goroutine阻塞上，而不是业务逻辑本身。
查 /debug/pprof/goroutine?debug=2 看协程是否堆积
响应慢但CPU不高？大概率是goroutine卡住了，不是算得慢，是等得久。
- 大量处于
select或chan receive状态：说明 channel 没人读、sender 已退出，或者下游服务没响应导致http.Client.Do一直挂起 - 集中卡在
database/sql.(*DB).QueryRow：连接池耗尽，或数据库慢查询未加索引 - 出现重复的
runtime.gopark调用栈：可能是锁竞争，配合runtime.SetMutexProfileFraction(1)后访问/debug/pprof/mutex验证
检查 http.Client 是否漏设超时
Go 默认的 http.Client 没有任何超时，一次失败调用就能拖垮整条请求链。
-
Timeout只控制总耗时，不覆盖 DNS 解析、TLS 握手、连接建立阶段 - 必须显式配置
Transport：包括DialContext.Timeout（连接）、TLSHandshakeTimeout（握手）、ResponseHeaderTimeout（响应头） - 高并发下还要设
MaxIdleConns和MaxIdleConnsPerHost，否则连接复用失效，排队等空闲连接
用 go tool trace 看调度与 STW 是否异常
当 P99 响应时间抖动大、偶发卡顿，pprof CPU 又看不出热点，就得看运行时调度行为。
立即学习“go语言免费学习笔记（深入）”；
- 运行
go tool trace后打开 Web UI，重点看 “Goroutine analysis” —— 如果大量 G 处于 “Runnable” 但长时间没被调度，说明P数不足或有系统线程阻塞 - 观察 “STW” 时间段：若单次 > 1ms，且频繁发生，说明 GC 压力大，需检查内存分配热点（比如
runtime.mallocgc占比高） - “Network blocking” 标签突出：说明 HTTP 客户端或 DB 驱动在等网络 I/O，而非 Go 代码执行慢
结合链路追踪确认瓶颈落在哪一跳
单靠本服务指标无法判断延迟是自己慢，还是下游慢。必须依赖 TraceId 对齐全链路。
- Span 之间出现长 Gap（比如 A 结束后 300ms 才开始 B）：说明本服务处理完后，发起下游调用前有阻塞（如锁、channel、未 await 的 goroutine）
- 某 Span 持续 >200ms 且标签含
db.statement：直接定位到慢 SQL，不用猜 - 同一 Trace 中多个短 Span（如 100+ 条
redis.get）：典型 N+1，不是缓存问题，是查询逻辑缺陷
真正难排查的，从来不是“哪里慢”，而是“为什么这个慢会传染到整个链路”——比如一个没设超时的 HTTP 调用，在下游卡住 5 秒，会导致本服务堆积 500 个 goroutine，进而拖垮所有其他请求。这种级联效应，必须从客户端配置、上下文传播、熔断策略三处同时堵住。
