pprof http服务启用后访问不到是因为仅导入net/http/pprof包只注册handler到defaultservemux，未调用http.listenandserve(":6060", nil)启动监听，导致/debug/pprof/路径始终返回404。
pprof HTTP服务启用后为什么访问不到
默认只注册路由，不启动HTTP服务，net/http/pprof 包只是把 handler 挂到 http.DefaultServeMux，你得自己监听端口。常见错误是导入了包但漏掉 http.ListenAndServe。
- 必须显式启动：加一行
go http.ListenAndServe("localhost:6060", nil)，否则http://localhost:6060/debug/pprof/一直 404 - 端口被占时会静默失败，建议捕获 error：
log.Fatal(http.ListenAndServe(":6060", nil)) - 生产环境别用
nil作为 handler，应限制路径或加 Basic Auth，否则任意人可下载堆栈、goroutine 等敏感数据
用 go tool pprof 分析 CPU 占用时采样时间不够
go tool pprof 默认只采样 30 秒，而 Go runtime 的 CPU profiler 实际每秒采样 100 次，低于 1 秒的采样几乎无意义——它会直接返回“no samples collected”。
- 手动指定时长：运行
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=60（不是?timeout=60） - 本地二进制分析要加
-seconds参数：go tool pprof -seconds=60 ./myapp，否则默认 30 秒且无法调整 - 注意：CPU profile 不是“越久越好”，超过 5 分钟可能掩盖瞬时峰值；推荐先跑 30–60 秒，再根据火焰图热点决定是否复测
集成 zap 后 pprof 日志干扰性能分析结果
zap 的 DebugLevel 或未关闭的 caller 字段会显著拖慢 pprof 采样期间的调度行为，导致火焰图出现大量 runtime.growslice 或 zap.(*CheckedEntry).Write 假热点。
- 性能分析期间务必禁用调试日志：
zap.NewProduction()已默认关闭caller和debug，但若用了自定义 config，需确认DisableCaller和DisableStacktrace均为true - 避免在 pprof 采样窗口内打日志：高频路径（如 HTTP 中间件）改用
logger.Check(zap.DebugLevel, "msg").Write(...)显式判断级别 - 切忌在
pprof.Profile.Start()前后调用fmt.Sprintf或json.Marshal—— 它们在 logger 判断是否输出前就执行，完全绕过日志级别控制
skywalking-go profiling 任务始终不触发
不是 agent 没装好，而是 OAP 没下发、服务没达标、或运行时没开开关 —— 三者缺一不可。
- OAP 必须启用 profiling 模块：检查
conf/application.yml中receiver-profiling是否启用，且profiling下的default或enabled: true已配置 - Go 二进制需带 profiling 支持：用
skywalking-go-agent -inject ./ -enable-profiling编译，且运行时设SW_AGENT_PROFILING_ENABLED=true - 触发条件很严格：默认只对“响应时间 > 端点平均耗时 × 2.0”的请求采样；若服务一直很稳，就永远不触发——手动构造一次慢请求（如
time.Sleep(2 * time.Second)）才能看到任务下发日志
真正卡住人的地方不在代码里，而在配置组合与时序判断：OAP 配置、agent 注入、运行时环境变量、慢请求触发、UI 任务参数设置——五者必须全部对齐，少一个环节 UI 上就永远灰着按钮。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
