pprof 默认看不到 CPU 火焰图，因其仅暴露采样接口且需主动触发至少30秒采集，否则报错“profile: total duration too short”。
pprof 为什么默认看不到 CPU 火焰图？
因为 net/http/pprof 默认只暴露采样接口，不自动启动 CPU profiling —— 它需要你主动触发至少 30 秒的采集（Go 1.20+ 要求最小 30s），否则返回空或报错 profile: total duration too short。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=60显式指定时长，别信默认值 - 服务必须已注册
net/http/pprof（比如http.ListenAndServe(":6060", nil)前调用pprof.Register()或导入_ "net/http/pprof"） - 本地分析时优先用
-http=localhost:8080启动交互式界面，比看原始 SVG 更快定位热点函数 - 若程序是短生命周期（如 CLI 工具），不能走 HTTP 接口，改用
runtime/pprof.StartCPUProfile+StopCPUProfile手动控制
内存分析总看到 runtime.mallocgc，但实际业务代码没出现？
这是典型“采样丢失”现象：默认 pprof heap 是采样型（runtime.MemProfileRate 默认 512KB），小对象分配被跳过，大对象又常由标准库间接触发，导致业务调用栈被截断。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 临时提高采样精度：启动前设环境变量
GODEBUG=madvdontneed=1（Linux）并运行时执行runtime.MemProfileRate = 1（注意仅限调试，会显著拖慢程序） - 用
go tool pprof -alloc_space替代默认的-inuse_space，查累计分配量，更容易暴露高频小对象泄漏点 - 检查是否误用
sync.Pool：Put 了但没 Get，或 Put 的对象含未清零字段，导致“假泄漏”（pprof 显示存活但实际可回收） - 对比
heap -dump和goroutine输出，若大量 goroutine 卡在chan receive或select，往往是 channel 缓冲区堆积引发内存滞留
线上服务不敢开 pprof？其实可以只开特定端点
net/http/pprof 注册的是整套路由（/debug/pprof/ 下所有子路径），但你可以只挂其中几个，避免暴露敏感信息（如 /goroutine?debug=2 含完整栈和局部变量）。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 别用
http.DefaultServeMux自动注册；手动注册需要的端点：mux.HandleFunc("/debug/pprof/profile", pprof.Profile)、mux.HandleFunc("/debug/pprof/heap", pprof.Handler("heap").ServeHTTP) - 禁止开放
/debug/pprof/cmdline（泄露启动参数）、/debug/pprof/symbol（可反查地址）、/debug/pprof/trace（高开销） - 加中间件限制 IP 或鉴权：比如只允许内网
10.0.0.0/8访问，或用简单 token 校验（?token=xxx） - 容器部署时，把 pprof 端口（如 6060）不映射到宿主机，仅通过
kubectl port-forward临时连通
pprof 分析结果里 show 无响应或 top 显示乱码？
常见于符号表缺失或二进制未保留调试信息。Go 编译默认带 DWARF，但加了 -ldflags="-s -w" 就会删掉所有符号，pprof 就只能显示地址（如 0x45d8a0）而无法还原函数名。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 构建时去掉
-s（strip symbol table）和-w（omit DWARF symbol table），至少保留一个用于调试的版本 - 若必须 strip，用
go build -gcflags="all=-l" -ldflags="-linkmode external -extldflags '-static'"配合外部符号文件（复杂，一般不推荐） - 交叉分析时确保 pprof 工具版本与目标 Go 版本一致（如 Go 1.21 编译的程序，别用 Go 1.19 的
go tool pprof） - 在容器中运行时，确认
/proc/sys/kernel/perf_event_paranoid≥ 2（否则 CPU profile 权限不足，返回空数据）
真正卡住的地方往往不是怎么画图，而是采样是否真实、符号是否在线、以及你看到的“高耗时函数”到底是在干业务逻辑，还是在等锁、等 IO、等 GC —— 这些得结合 trace 和 goroutine 分析交叉验证。
