pprof 仅定位性能瓶颈而非直接优化代码，需正确导入 net/http/pprof 并手动注册路由至自定义 mux，采样类型（cpu/heap/goroutine）须按需选择，分析依赖 go tool pprof 命令行工具，生产环境须限制访问与采样开销，并区分 flat（自身耗时）与 cum（累计耗时）列。
pprof 本身不直接“优化”代码，它只暴露瓶颈在哪——80% 的性能问题靠它定位到 http.HandlerFunc、runtime.mallocgc 或某个循环里反复调用的 json.Unmarshal 就够了。
启用 pprof HTTP 接口要加 net/http/pprof，且必须注册到运行中的 mux
很多人跑完程序发现 localhost:6060/debug/pprof/ 404，根本原因是没导入或没挂路由。
-
import _ "net/http/pprof"是必须的，下划线导入会自动执行其init() - 但仅导入不够：如果用了自定义
http.ServeMux（比如mux := http.NewServeMux()），得手动注册：mux.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index)) mux.Handle("/debug/pprof/profile", http.HandlerFunc(pprof.Profile)) mux.Handle("/debug/pprof/trace", http.HandlerFunc(pprof.Trace)) - 若用默认
http.DefaultServeMux（即直接调http.HandleFunc），导入后访问/debug/pprof/就能打开索引页
采样类型选错会导致关键信息丢失
pprof 提供多个 profile 类型，cpu 和 heap 最常用，但它们采集逻辑完全不同，混用会误判。
-
/debug/pprof/profile?seconds=30采集 CPU 使用：只在 goroutine 正在执行时采样，适合找“谁在疯狂计算” -
/debug/pprof/heap是内存快照（默认是 in-use objects）：反映当前堆上还活着的对象，不是分配总量；想看“谁分配最多”，要加?gc=1或用go tool pprof -alloc_space -
/debug/pprof/goroutine?debug=2输出所有 goroutine 的栈，比runtime.Stack()更全，适合排查泄漏或死锁前兆
本地分析 pprof 数据必须用 go tool pprof，不能只靠浏览器看
网页版 /debug/pprof/ 只展示简单火焰图和 top 列表，真正定位要靠命令行交互式分析。
立即学习“go语言免费学习笔记（深入）”；
- 下载 profile：
wget http://localhost:6060/debug/pprof/profile?seconds=30 -O cpu.pprof - 启动交互式分析：
go tool pprof cpu.pprof，然后输入top、web（生成 SVG 火焰图）、list myFunc查具体函数汇编或源码行 - 注意：若二进制没有调试符号（如用
go build -ldflags="-s -w"），list会失败，web也只显示函数名不带行号 - 对比两个 profile（如优化前后）：
go tool pprof --base before.pprof after.pprof，再用top看 delta
生产环境开启 pprof 要限制访问和采样开销
pprof 不是零成本——CPU profile 默认每毫秒中断一次，高 QPS 服务可能增加 5–10% 开销；HTTP 接口若暴露公网，等于交出进程内存快照。
- 用反向代理（如 Nginx）限制
/debug/pprof/只允许内网 IP 访问 - 避免长期开启
block或mutexprofile，它们需要额外 runtime hook，影响更大 - 临时诊断可用
runtime.SetBlockProfileRate(1)，但上线前务必关掉（设为 0） - 容器环境中，别把
6060端口直接映射出来；优先用kubectl exec -it pod -- go tool pprof http://localhost:6060/debug/pprof/profile
最常被忽略的一点：pprof 报告里的“flat”和“cum”列含义不同——前者是该函数自身耗时（不含调用子函数），后者是包含所有子调用的累计时间。看优化效果时，盯 flat；查调用链路时，看 cum。搞反了，就容易去优化一个其实只占 0.1% 的顶层 wrapper 函数。
