pprof需明确目标、正确采集路径和带调试符号的二进制文件，否则top显示runtime.mcall或十六进制地址；/debug/pprof/返回404因未注册handler，须用默认mux或显式挂载；go tool pprof必须同时传入二进制文件才能解析函数名；heap profile需加?gc=1才反映真实存活对象；goroutine profile需加?debug=2才显示全部状态。
pprof 不是“开个端口就自动出答案”的工具，它必须配合明确目标、正确采集路径和带调试符号的二进制文件，否则 top 输出全是 runtime.mcall 或十六进制地址，根本没法对应到你的业务函数。
/debug/pprof/ 返回 404 怎么办
最常见原因是没走默认路由注册路径——_ "net/http/pprof" 的 init() 只向 http.DefaultServeMux 注册 handler。如果你用了 http.NewServeMux() 却没手动挂载，端点就不存在。
- 用默认 mux：确保
http.ListenAndServe(":6060", nil)第二个参数为nil - 用自定义 mux：必须显式添加所有路由，例如：
mux.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index))、mux.Handle("/debug/pprof/profile", http.HandlerFunc(pprof.Profile))等 - 验证方式：启动后执行
curl http://localhost:6060/debug/pprof/，返回 404 就说明没注册成功 - 注意中间件拦截：Gin/Echo 等框架若全局注册了中间件（如鉴权、日志），可能把
/debug/pprof/拦截掉，需单独放行
go tool pprof top 全是 runtime.mcall 或地址
这是线上调优最高频的误操作：只传 profile 文件，不传二进制文件。Go 的 CPU profile 采集的是运行时内存地址，没有原始可执行文件，go tool pprof 就无法把地址映射回函数名，只能显示匿名帧。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 错误命令：
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30 - 正确做法必须同时提供二进制：
对go run启动的服务：先go build -o myapp .，再./myapp &，最后go tool pprof myapp http://localhost:6060/debug/pprof/profile?seconds=30
对go test：用go test -cpuprofile cpu.out -o benchmark.test .，然后go tool pprof benchmark.test cpu.out - 验证是否加载成功：进入交互模式后输入
top，若第一列出现函数名（如main.CPUHeavyFunc）且占比合理，说明符号已解析；若只有runtime.mcall或空白行，说明仍失败 - 构建时别加
-ldflags="-s -w"：这会剥离符号表，导致无法映射函数名
/debug/pprof/heap 显示 inuse_space 持续上涨但 GC 后不降
/debug/pprof/heap 默认返回的是「当前堆中存活对象」快照（inuse_space），但它不等于内存泄漏——GC 后仍不下降才值得怀疑。关键要看采样参数是否带 ?gc=1。
- 不加
?gc=1：返回的是分配总量（alloc_objects），包含已被 GC 回收但尚未被复用的内存，容易误判 - 加
?gc=1：强制触发一次 GC 后再采样，反映真实存活对象，适合排查泄漏 - 单次快照不可靠：必须对比多次
/debug/pprof/heap?gc=1结果，间隔 30 秒以上，观察inuse_space是否持续增长且无对应业务释放动作 - 更准的方式是看累计分配：
go tool pprof -alloc_space http://localhost:6060/debug/pprof/heap，然后top，如果strings.Builder.Write或encoding/json.(*encodeState).marshal排前三，说明高频拼接或序列化在不断 new 对象
goroutine 数量暴涨却查不到泄漏点
/debug/pprof/goroutine 默认只返回状态为 running 或明显阻塞（如 chan send）的 goroutine，大量“活着但不活跃”的 goroutine（比如卡在 select 等待、或刚创建还没执行）会被过滤掉。
- 必须加
?debug=2：才能看到所有 goroutine 的完整调用栈，包括runnable、waiting、syscall状态 - 常见泄漏原因：
for-select缺少default分支、HTTP 客户端未设超时、channel 未关闭、defer 中启动 goroutine 但没控制生命周期 - 用
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2后，top关注处于chan receive或select状态的 goroutine 数量是否随请求增长 - 注意
sync.Pool缓存的对象不会出现在 heap profile 里，但若 Pool 的New函数本身创建大对象（如bytes.Buffer底层切片过大），仍会推高AllocSpace
真正难的不是跑通命令，而是判断该采哪个 profile、在哪一刻采、采多久，以及怎么从一堆 runtime 帧里揪出那行真正有问题的业务代码——这些没法靠工具自动完成，得靠你对程序行为的理解和反复验证。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
