pprof.StartCPUProfile未生成文件是因为必须显式调用pprof.StopCPUProfile才能写入磁盘，panic退出、defer位置错误或未Close文件均会导致失败；/debug/pprof 404是因未注册到自定义ServeMux；flat%与cum%差异大说明瓶颈在下游调用；采样有性能开销，需合理设置频率与时长。
pprof.StartCPUProfile 为什么没生成 profile 文件
调用 pprof.StartCPUProfile 后没看到文件，大概率是没调用 pprof.StopCPUProfile —— 它不会自动 flush，必须显式停止才能写入磁盘。常见错误是程序 panic 退出、或 defer 写错位置导致没执行到 stop。
- 确保
pprof.StartCPUProfile和pprof.StopCPUProfile成对出现，且后者在 defer 中或明确路径上执行 - 不要依赖进程退出自动保存：Go 的
runtime/pprof不会做这事 - 如果写入的是
*os.File，记得Close()，否则可能缓冲未落盘 - Windows 下注意路径权限，避免写到
C:\Program Files\这类受限目录
HTTP 服务中启用 /debug/pprof 但访问 404 或无数据
默认 Go 的 /debug/pprof 是注册在 http.DefaultServeMux 上的，如果你用了自定义 http.ServeMux（比如 Gin、Echo、或手动 new 一个），它压根没被挂载。
- 确认是否调用了
http.ListenAndServe且没传自定义 mux；如果传了，得手动注册：mux.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index)) - 检查路由是否被中间件拦截（如 Gin 的
router.Use()拦截了所有请求，包括 /debug/pprof） - 浏览器直接访问
/debug/pprof/看首页，再点profile?seconds=30抓 CPU 数据；别只看/debug/pprof/profile—— 它是重定向入口，不带参数会 302 到首页 - 生产环境别长期开着，尤其别暴露在公网；
/debug/pprof不鉴权，谁都能下载堆栈和 CPU 数据
go tool pprof 分析时 flat% 和 cum% 差距极大，怎么看瓶颈
flat% 是函数自身耗时占比（不含调用子函数），cum% 是从当前函数到叶子节点的累计耗时。两者差得多，说明这个函数主要是“转发”或“调度”，真正干活的在它调用的下游里。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 优先看
cum%高但flat%低的函数——比如runtime.findrunnablecum%95% 但flat%几乎为 0，说明调度器忙，实际瓶颈在 goroutine 大量阻塞或 GC 压力大 - 用
pprof> top -cum查调用链顶端，再用pprof> list 函数名看具体哪行代码在调用慢函数 - 警惕
io.Copy、json.Marshal、fmt.Sprintf这类看似简单但 cum% 很高的操作，它们常因数据量大或频繁调用成为隐性瓶颈 - 别只盯着 top10，有时第 12 行一个
time.Sleep(100 * time.Millisecond)在 hot loop 里，cum% 只有 2%，但拖慢整个流程
生产环境采集 CPU profile 会影响性能吗
会，但可控。Go 的 CPU profiling 使用 setitimer 发送 SIGPROF 信号，默认每 10ms 采样一次（即 100Hz），单次采样开销约 1–2μs，但高频信号本身有上下文切换成本。
立即学习“go语言免费学习笔记（深入）”；
- 降低频率能显著减负：
runtime.SetCPUProfileRate(1000)设为 1kHz（1ms 一次）适合调试；设为 100（10ms）是默认值；线上建议 50（20ms）或更低 - 采样时间别贪长：30 秒 profile 文件可能几 MB，解析卡顿；通常 10–20 秒足够定位热点
- 避免在高负载时段全量开启；可针对特定 handler 加逻辑开关，比如只对某个 traceID 或 query 参数开启
- 注意：
SetCPUProfileRate(0)会关闭采样，但已 start 的 profile 不会自动 stop，仍需手动调用StopCPUProfile
pprof 不是银弹，它告诉你「哪里慢」，但不解释「为什么慢」；比如看到 sync.(*Mutex).Lock cum% 高，得接着查是谁在争抢这把锁、锁粒度是否合理、有没有死锁倾向——这些得靠日志、trace 和代码逻辑交叉验证。
