pprof 默认仅注册路由不启动服务，需手动挂载到 HTTP server；路径末尾斜杠不可省略；CPU 采样至少 30 秒；heap 分析应使用 ?alloc_space 查分配源头；goroutine 泄漏需比对 debug=2 栈信息。
pprof 启动后访问 /debug/pprof/ 返回 404？
默认情况下，net/http/pprof 只注册路由，不自动启动 HTTP 服务。你得手动挂到一个运行中的 server 上，或者用 http.DefaultServeMux 并确保它被监听。
- 常见错误：只 import
"net/http/pprof"就以为能访问 —— 实际上它只是“悄悄注册”，没 server 就没响应 - 正确做法：要么调用
http.ListenAndServe(":6060", nil)（依赖DefaultServeMux），要么显式挂载：http.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index)) - 注意路径大小写：
/debug/pprof/末尾斜杠不能少，否则重定向可能失败；/debug/pprof/cmdline这类子路径也必须完全匹配 - 如果用了 Gin、Echo 等框架，不能直接依赖
DefaultServeMux，得用中间件桥接，比如 Gin 中需手动r.GET("/debug/pprof/*pprof", gin.WrapH(http.DefaultServeMux))
CPU profile 采样时长不够或始终显示 runtime.mcall？
pprof 的 CPU 分析依赖系统信号（SIGPROF）定时中断，采样太短或程序没在跑 CPU 密集型逻辑，就会堆满调度器底层函数，看不出业务瓶颈。
- 最少采样 30 秒：用
curl -o cpu.pprof "http://localhost:6060/debug/pprof/profile?seconds=30"，别用默认 15 秒 - 确保目标代码正在执行：比如压测接口、循环处理数据；空闲状态抓的 profile 基本全是
runtime.futex和runtime.mcall - 避免在本地开发机上跑 —— macOS 的
perf支持弱，Linux 更准；Docker 容器里记得加--cap-add=SYS_PTRACE，否则无法 attach - 生成的
cpu.pprof别直接打开看文本，用go tool pprof cpu.pprof进交互模式，输入top或web才能看到调用热点
heap profile 显示大量 runtime.mallocgc 却找不到谁在分配？
内存分析默认是「实时堆」快照（/debug/pprof/heap），反映的是当前存活对象；真要查分配源头，得用「分配总量」视图（?alloc_space 或 ?alloc_objects）。
- 默认
/debug/pprof/heap是 in-use 状态，GC 后很多对象已释放，看不到历史分配大户 - 改用：
curl -o heap_alloc.pprof "http://localhost:6060/debug/pprof/heap?alloc_space=1"，这会统计所有 malloc 调用累计字节数 - 配合
go tool pprof --alloc_space heap_alloc.pprof，再输top，才能看到json.Unmarshal或strings.Repeat这类高频分配点 - 注意 GC 频率影响：如果每秒 GC 多次，
inuse_space会极小，但alloc_space会爆炸 —— 此时不是内存泄漏，而是分配太猛
用 go tool pprof 看不出 goroutine 泄漏？
/debug/pprof/goroutine 默认返回的是「正在运行 + 等待中」的 goroutine 列表（stack traces），但文本格式难定位；真正要确认泄漏，得比对多次快照的 goroutine 数量变化和共性调用栈。
立即学习“go语言免费学习笔记（深入）”；
- 先看总数：
curl "http://localhost:6060/debug/pprof/goroutine?debug=1" | grep "goroutine" | wc -l，压测前后对比是否持续上涨 - 导出完整栈：
curl -s "http://localhost:6060/debug/pprof/goroutine?debug=2" > goroutines.txt，搜索chan receive、select、time.Sleep等阻塞关键词 - 常见泄漏点：HTTP handler 里启 goroutine 但没做 cancel 控制；
for range time.Tick()忘了用context关闭；第三方库的 long-polling client 没 Close -
go tool pprof对 goroutine profile 支持有限，别指望它画火焰图 —— 直接读debug=2的文本更可靠
pprof 不是开箱即用的「性能答案机」，它暴露的是现象，不是原因。最常被忽略的其实是采样上下文：你抓的是 idle 状态还是 peak QPS 下的 profile？有没有排除日志、监控埋点这些干扰分配的 side effect？调用栈里出现三次 http.(*conn).serve 并不奇怪，但若每个都带着同一段未关闭的 io.Copy，那才是线索。
