根本原因是pprof.StartCPUProfile不自动写入磁盘，必须显式调用pprof.StopCPUProfile才能将采样数据刷入文件；常见错误包括panic退出、defer位置错误、未Close文件句柄或未注册/debug/pprof到自定义ServeMux。
pprof.StartCPUProfile 为什么调用后没生成文件？
根本原因：它不自动写入磁盘，只把采样数据写进你传入的 *os.File，必须手动打开文件并保持句柄打开。常见错误是传了 os.Stdout 或临时 os.Create 后立刻 Close()，导致数据丢失或 panic。
- 必须用
os.Create打开一个可写文件，且在整个 profiling 过程中不能关闭该文件句柄 - 如果程序提前退出（比如 panic 或 os.Exit），需用
defer确保pprof.StopCPUProfile()被调用，否则采样线程不会停止，文件可能为空或损坏 -
pprof.StartCPUProfile返回error，但多数人忽略它；若传入 nil 或不可写文件，会直接返回err != nil
如何正确启动和停止 CPU profiling？
关键不是“开启”，而是“控制生命周期”——Start 和 Stop 必须成对、在同一个 goroutine 中执行，且 Stop 前必须保证 Start 成功。
- 先检查
err := pprof.StartCPUProfile(f)，非 nil 就别继续 - Stop 必须显式调用，不能依赖 GC 或进程退出；否则 profile 数据不完整，
go tool pprof解析时会报failed to open profile: unrecognized profile format - 典型安全写法：
if f, err := os.Create("cpu.pprof"); err == nil { defer f.Close() if err = pprof.StartCPUProfile(f); err != nil { log.Fatal(err) } defer pprof.StopCPUProfile() // 注意：这行必须在 Start 成功后才 defer }
StartCPUProfile 的采样频率受哪些因素影响？
Go 运行时默认使用基于信号的周期性采样（约 100Hz），但实际频率不固定，取决于调度器状态和系统负载，**不是用户可控参数**。想提高精度只能靠延长 profiling 时间，而非调高频率。
- 底层依赖
setitimer（Unix）或SetThreadExecutionState（Windows），Go 不暴露采样间隔配置项 - 短于 100ms 的 profiling 很可能采集不到有效样本，建议至少运行 1–5 秒再 Stop
- goroutine 频繁阻塞（如大量 channel 操作、syscall）会导致采样点集中在 runtime 函数上，掩盖业务逻辑热点，此时应结合
runtime/pprof.Do对特定代码段打标
生成的 cpu.pprof 文件怎么验证是否有效？
别急着扔进 go tool pprof，先用最简命令确认文件结构合法：
立即学习“go语言免费学习笔记（深入）”；
- 运行
file cpu.pprof，应输出类似cpu.pprof: data（不是 text 或 empty） - 执行
go tool pprof -symbolize=none cpu.pprof，若提示failed to fetch any profiles或unrecognized profile format，基本是 Stop 没调用或文件被截断 - 用
strings -n 8 cpu.pprof | head -5查看前几行二进制内容里是否有profile字符串——这是 Go profile 的 magic header 标识
真正容易被忽略的是：StopCPUProfile() 必须在所有 goroutine 完全退出前调用，否则 runtime 可能仍在写入，文件末尾不完整。多协程场景下，建议用 sync.WaitGroup 等待业务逻辑结束，再 Stop。
