先用 pprof CPU profile 定位热点，再查 goroutine 泄漏、GC 频率及系统级干扰，分层排查 Go 服务变慢根因。
看 pprof 的 CPU profile 是否有明显热点
Go 程序变慢，第一反应不是加日志也不是改代码，而是跑一次 pprof。它能告诉你「CPU 时间实际花在哪」，而不是你以为花在哪。
- 启动时加
net/http/pprof：在主程序里注册路由http.ListenAndServe(":6060", nil)，确保已导入_ "net/http/pprof" - 采集 30 秒 CPU profile：
wget -O cpu.pprof "http://localhost:6060/debug/pprof/profile?seconds=30" - 分析：
go tool pprof cpu.pprof，进入交互后用top看前 10 耗时函数，用web生成调用图（需安装 graphviz） - 注意：如果
runtime.mcall或runtime.gopark占比高，说明不是 CPU 密集型问题，而是协程阻塞或调度等待——该去看 goroutine profile 或 trace
查 goroutine 泄漏或死锁：用 /debug/pprof/goroutine?debug=2
大量 goroutine 堆积是 Go 服务变慢的常见原因，尤其在 HTTP 客户端未设超时、channel 未关闭、select 漏写 default 分支时。
- 执行
curl 'http://localhost:6060/debug/pprof/goroutine?debug=2'，输出会显示每个 goroutine 的当前栈帧 - 重点关注状态为
IO wait、semacquire、chan receive且长期不变的 goroutine - 常见泄漏模式：
http.Client复用但没设Timeout或Transport.IdleConnTimeout；数据库连接池未 close；定时器time.Ticker启动后没 stop - 若返回内容巨大（几万行），基本可判定泄漏；此时配合
go tool pprof http://localhost:6060/debug/pprof/goroutine可按栈聚合统计
确认 GC 频率和停顿是否异常：看 gc trace 和 GOGC 设置
GC 不是“偶尔发生”，而是每秒可能触发多次——尤其当堆增长快、GOGC 设得过高（如默认 100）或内存分配模式不合理时，会导致 STW 时间肉眼可感。
- 开启 GC trace：
GODEBUG=gctrace=1 ./your-binary，观察输出中类似gc 12 @12.345s 0%: 0.02+1.2+0.03 ms clock, 0.16+0.2/0.8/0.1+0.24 ms cpu, 12->13->8 MB, 14 MB goal, 8 P的行 - 关键指标：第三段数字（如
0.02+1.2+0.03）分别对应 mark setup / mark / sweep 时间；若 mark 时间持续 >1ms，或每秒 GC 超过 2–3 次，就要警惕 -
GOGC=20比默认 100 更激进，适合低延迟场景；但别盲目调低，可能引发更频繁 GC —— 先用go tool pprof http://localhost:6060/debug/pprof/heap看对象分配源头 - 避免在 hot path 中触发小对象高频分配，比如循环里拼接字符串用
fmt.Sprintf，应改用strings.Builder
验证系统级干扰：检查 strace、perf 和内核参数
Go 程序再干净，也跑在操作系统上。某些性能退化根本不在 Go 层，比如被 cgroup 限频、磁盘 I/O 阻塞、NUMA 绑核不均。
立即学习“go语言免费学习笔记（深入）”；
- 用
strace -p $(pidof your-binary) -e trace=epoll_wait,read,write,connect -T看系统调用是否卡住（特别是epoll_wait返回时间突增） - 用
perf record -p $(pidof your-binary) -g -- sleep 30+perf report查看是否陷入内核态太久（如ext4_writepages、tcp_sendmsg） - 检查是否启用了透明大页（THP）：
cat /sys/kernel/mm/transparent_hugepage/enabled，Go 对 THP 敏感，建议设为never - 容器环境务必确认
cpu.shares/cpu.cfs_quota_us未过度限制，docker stats或cgroups文件系统可查实时配额使用率
真正卡住排查的，往往不是某一行代码写错了，而是多个层面叠加：goroutine 堆积 → 内存上涨 → GC 加剧 → 协程调度延迟升高 → HTTP 超时堆积 → 更多 goroutine 创建……动手前先分清是 Go 运行时问题、代码逻辑问题，还是基础设施问题。
