线上热路径持续剖析需采用低频、短时、带时间戳的轮转采样，而非拉长单次采样；默认pprof阻塞式采集会挂起调度器、增加延迟且无法定位瞬时热点，10μs粒度CPU开销超5%不可接受，100Hz已足够；轮转需控制频率、时长与元数据，推荐10分钟轮次+10秒采集+时间戳打标+对象存储；多profile比对用diff_base和Peek看趋势，避免web混叠稀释热点；采样窗口须对齐业务节奏，防止错过峰值。
线上热路径持续剖析不是靠拉长单次采样时间，而是用低频、短时、带时间戳的轮转采样，把 CPU profile 拆成可比对的时序切片——否则你拿到的只是一个模糊的“平均热点”，根本看不出哪段代码在凌晨三点突然变热。
为什么不能一直开着 pprof/profile？
默认的 go tool pprof http://.../profile 是阻塞式采集，会挂起所有 P（Goroutine 调度器）并强制同步记录调用栈。持续开 30 秒以上，CPU 开销会线性上升，服务延迟抖动明显；更关键的是，它无法告诉你“这个热点是稳定存在，还是只在某个请求链路里爆发”。
- 真实生产中，
runtime.SetCPUProfileRate(100000)（即 10μs 粒度）会让 CPU 开销飙升到 5%+，完全不可接受 - Go 运行时默认的 100Hz（10ms）采样已足够定位热路径，再密反而引入噪声
- 长期开启不轮转，profile 文件体积爆炸，且丢失时间维度——你无法回答“内存分配速率是否在每小时增长”这类问题
pprof 轮转采样的实操配置
核心是控制三个变量：采样频率、单次时长、存储元数据。我们用 10 分钟轮次 + 10 秒 CPU 采集 + 自动打标，实测整体 CPU 损耗
- 用
http.ListenAndServe("localhost:6060", nil)单独起一个 debug 端口，和业务流量隔离 - 写个后台 goroutine，每 10 分钟触发一次：
curl -s "http://localhost:6060/debug/pprof/profile?seconds=10" > /tmp/cpu_$(date +%s).pb.gz - 务必加
-s静默模式，避免 curl 自身日志污染 stdout - 文件名必须含时间戳（如
cpu_1729332000.pb.gz），后续才能用pprof -http=:8080 cpu_*.pb.gz批量比对 - 别存本地磁盘——用
os/exec调aws s3 cp或gsutil cp推到对象存储，避免填满根分区
如何从一堆 .pb.gz 文件里看出热路径变化？
单个 profile 只能看“此刻谁最忙”，但多个带时间戳的 profile 合并后，才能识别“谁在变忙”。关键命令不是 top，而是 diff 和 peek。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 对比两个时间点的 CPU 热点：
pprof -diff_base cpu_1729332000.pb.gz cpu_1729335600.pb.gz，输出正负变化的函数耗时差值 - 用
pprof -http=:8080 cpu_*.pb.gz启服务后，在浏览器里点 “View → Peek”，输入函数名（如json.Unmarshal），直接看到它在每个 profile 中的占比趋势图 - 如果发现某个 handler 在凌晨 3 点的 profile 中占比突增 40%，但其他时间正常，大概率是定时任务或下游重试风暴导致——这时再结合 trace 或日志查具体请求 ID
- 注意：不要用
web命令生成单张火焰图来“总览”，那会把所有时间片混在一起，热路径会被稀释掉
最容易被忽略的是采样窗口和业务节奏的错位：比如你设 10 分钟轮次，但核心定时任务每 15 分钟跑一次，结果每次采集都刚好错过峰值。上线前务必用 date 对齐业务调度周期，宁可手动改 cron，也不要迷信固定间隔。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
