pprof服务未启动需检查net/http/pprof是否正确注册，确保下划线导入或手动注册路由；cpu采样时长应按需控制，避免默认30秒；火焰图需用go tool pprof生成并过滤噪声；生产环境应按需触发而非全量开启。
pprof 服务没起来？检查 net/http/pprof 是否已注册
Go 的 pprof 默认不自动暴露 HTTP 接口，必须显式导入并注册。常见错误是只 import 了 net/http/pprof 却没调用任何注册函数，导致 /debug/pprof/ 返回 404。
- 确保在 main 包中执行
import _ "net/http/pprof"（下划线导入会触发包 init 函数） - 如果用了自定义
http.ServeMux，需手动注册：mux.HandleFunc("/debug/pprof/", http.HandlerFunc(pprof.Index)) -
微服务常使用独立路由前缀（如
/metrics），别把/debug/pprof拦截或重写掉了 - 启动后 curl -v http://localhost:8080/debug/pprof/ 确认返回 HTML 列表，否则后续所有分析都无效
采样时间太短或太长？用 runtime/pprof 控制 CPU profile 时长
HTTP 接口 /debug/pprof/profile 默认采样 30 秒，对高并发微服务可能过长（阻塞请求）、对低频问题又可能错过热点。直接调用 runtime/pprof 更可控。
- 用
pprof.StartCPUProfile(f)+pprof.StopCPUProfile()手动启停，适合在特定 RPC 入口或慢请求路径中埋点 - 避免在 goroutine 中无保护地多次 Start/Stop ——
StartCPUProfile是全局单例，重复调用 panic - 采样文件建议用
os.CreateTemp生成唯一路径，防止多实例覆盖；临时文件记得 deferf.Close() - 生产环境慎用 30 秒默认值：一次采样可能吃掉数百 MB 内存，尤其 GC 频繁时 profile 数据膨胀明显
火焰图看不懂？用 go tool pprof 提取关键路径
原始 profile 文件是二进制格式，直接打开只能看到文本摘要。火焰图能直观定位热点函数，但需要正确生成和过滤。
Codex Auth Cleaner
下载
一款AI工具，主要用于Monitor and clean up invalid Codex authentication files in CPA. Check quota status, disable files returning 401 errors, and perform dual verification before deletion.，适合需要提升相关任务效率的用户。
- 生成 SVG 火焰图：
go tool pprof -http=:8081 cpu.pprof（自动启动本地服务，访问 http://localhost:8081） - 排除 runtime 和 stdlib 噪声：
go tool pprof -focus=YourServiceName cpu.pprof，比-ignore=runtime更精准 - 微服务常有大量 HTTP handler wrapper（如 middleware、trace 注入），用
-trimpath去掉 GOPATH 路径前缀，让函数名更干净 - 注意采样单位：CPU profile 显示的是“采样时正在执行的栈”，不是耗时绝对值；占比 5% 的函数未必是瓶颈，要看它是否被高频调用或阻塞下游
线上服务不敢开 pprof？用 pprof.Profile 按需触发
全量开启 /debug/pprof 有安全风险，且可能被恶意拉取堆内存数据。更稳妥的做法是按需启用，配合信号或管理端点控制。
- 监听
SIGUSR1信号触发 profile：signal.Notify(c, syscall.SIGUSR1); - 在健康检查端点（如
/health?profile=cpu）里加白名单校验，仅允许内网 IP 或带 secret token 的请求 - profile 文件写入前先检查磁盘空间：
stat, _ := os.Stat("/tmp"); if stat.Avail - 别依赖
pprof.Lookup("goroutine").WriteTo抓 goroutine dump —— 它会阻塞所有 goroutine，微服务中极易引发雪崩
pprof 不是开关一开就出答案的黑盒，CPU 瓶颈往往藏在锁竞争、channel 阻塞或低效序列化里，profile 只告诉你“哪段代码花时间”，不解释“为什么花时间”。盯着 runtime.chansend 或 sync.(*Mutex).Lock 占比高时，得去翻业务代码里的 channel 容量设置和 mutex 作用域。
