go程序卡顿主因是goroutine阻塞而非代码慢，需查/debug/pprof/goroutine?debug=2看堆积状态：chan receive/select堆积说明channel无人读或sender退出；queryrow集中卡住多因连接池耗尽或db延迟；runtime.gopark重复出现提示锁竞争；net.(*polldesc).wait停顿表明网络i/o等待；http.client必须显式配置transport各阶段超时，避免默认无超时拖垮链路。
Go 程序卡顿，90% 不是代码慢，而是 goroutine 卡在等——等 channel、等网络、等锁、等数据库连接，甚至等一个没设超时的 http.Client.Do。
查 /debug/pprof/goroutine?debug=2 看堆积状态
这是定位卡顿的第一步，也是最直接的证据。启动服务时导入 _ "net/http/pprof"，然后访问该路径，你会看到所有 goroutine 的当前栈帧和状态。
- 大量处于
chan receive或select：说明 channel 没人读，或 sender 已退出但 receiver 还在等；也可能是 context 被 cancel 后未及时退出 - 集中卡在
database/sql.(*DB).QueryRow：不是 SQL 慢，很可能是连接池耗尽（maxOpenConns太小）或下游 DB 响应延迟高 - 反复出现
runtime.gopark调用栈：大概率是锁竞争，配合runtime.SetMutexProfileFraction(1)后查/debug/pprof/mutex验证 - 大量 goroutine 停在
net.(*pollDesc).wait：HTTP 客户端或 Redis/DB 驱动在等网络 I/O，不是 Go 代码执行慢
检查 http.Client 是否漏设超时
Go 默认的 http.Client 没有任何超时，一次失败调用就能拖垮整条请求链。只设 Timeout 不够，它不覆盖 DNS 解析、TLS 握手、连接建立等阶段。
- 必须显式配置
Transport：DialContext.Timeout（连接）、TLSHandshakeTimeout（握手）、ResponseHeaderTimeout（响应头） - 高并发下还要设
MaxIdleConns和MaxIdleConnsPerHost，否则连接复用失效，goroutine 排队等空闲连接 - 别用全局默认 client；不同下游服务建议配独立 client，避免一个慢接口拖垮全部
用 go tool trace 看调度行为是否异常
当 P99 延迟抖动大、CPU 使用率不高、pprof CPU profile 又看不出热点时，就得看运行时调度细节。
- 打开 Web UI 后重点看 “Goroutine analysis”：如果大量 G 处于
Runnable但长时间没被调度，说明GOMAXPROCS设得过大（尤其容器中），P 数过多导致调度器内耗 - 观察 “STW” 时间段：单次 > 1ms 且频繁发生，说明 GC 压力大，要查
runtime.mallocgc分配热点 - “Network blocking” 标签突出：确认是 I/O 等待，而非业务逻辑阻塞；此时优化方向是超时、重试、连接池，不是改算法
结合链路追踪确认瓶颈落在哪一跳
单靠本服务指标无法判断延迟是自己慢，还是下游慢。必须依赖 TraceId 对齐全链路。
- Span 之间出现长 Gap（比如 A 结束后 300ms 才开始 B）：说明本服务处理完后，在发起下游调用前有阻塞（如锁、channel、未 await 的 goroutine）
- 某 Span 持续 >200ms 且标签含
db.statement：直接定位到慢 SQL，不用猜 - 同一 Trace 中出现 100+ 条
redis.get：典型 N+1，不是缓存问题，是查询逻辑缺陷
真正难排查的，从来不是“哪里慢”，而是“为什么这个慢会传染到整个链路”——比如一个没设超时的 HTTP 调用，在下游卡住 5 秒，本服务所有 goroutine 就跟着挂起 5 秒，还可能引发级联超时。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
