go-torch在生产环境基本不能直接用，因其依赖的net/http/pprof接口默认仅监听localhost，且工具多年未维护、不兼容新版go符号解析，容器中缺乏perf权限，采样时长与输出格式均不可控。
go-torch 为什么在生产环境基本不能直接用
因为 go-torch 依赖 go tool pprof 的 net/http/pprof 接口，而该接口默认只监听 localhost:6060，生产服务通常不暴露这个端口，也不允许外部直连。更关键的是，go-torch 本身已多年未维护（最后提交在 2019 年），对 Go 1.20+ 的 symbol 解析有兼容问题，生成的火焰图常出现 ??? 或函数名截断。
- 它默认调用
perf（Linux）或profile（macOS），但容器环境往往没装perf，也无权限执行 - 采集时长硬编码为 30 秒，无法指定，线上突发毛刺可能错过
- 输出 SVG 依赖
flamegraph.pl，脚本路径、Perl 版本、Unicode 支持都容易出错
替代方案：用原生 pprof + 简单命令链生成可用火焰图
Go 官方 go tool pprof 已完全覆盖 go-torch 功能，且持续更新。只要服务开启了 /debug/pprof/profile（默认开启），就能安全导出、本地分析。
- 先确认服务是否可访问：
curl -s http://your-service:6060/debug/pprof/profile?seconds=30 | head -c 100—— 应返回二进制头部，不是 404 或连接拒绝 - 本地生成火焰图只需一条命令：
go tool pprof -http=:8080 - 若需离线 SVG：
go tool pprof -svg flame.svg - 注意：不要用
pprof -raw，它输出的是原始 profile 数据，不能直接喂给flamegraph.pl
容器环境里怎么安全采集 CPU profile
Kubernetes Pod 默认禁止 perf_event_open 系统调用，且 go-torch 试图在容器内运行 perf 必然失败。必须绕过内核采样，改用 Go 运行时自带的 wall-clock profiler。
- 确保启动参数含
-gcflags="all=-l"（禁用内联）和-ldflags="-s -w"（保留符号表），否则火焰图全是runtime.goexit - 用
/debug/pprof/profile而非/debug/pprof/trace——后者开销大、易拖垮服务，且火焰图意义弱 - 如果服务用了 Istio 等 sidecar，注意请求可能被拦截；应直连 Pod IP + port，或用
kubectl exec在容器内 curl 自己：kubectl exec my-pod -- curl -s localhost:6060/debug/pprof/profile?seconds=15 - 避免在高负载节点上同时跑多个 profile 采集，CPU profile 本身会带来 ~5% 额外开销
火焰图里看到大量 runtime.mcall 怎么办
这不是 bug，是 Go 调度器正常行为。但若占比超 20%，说明 goroutine 频繁阻塞或调度压力大，常见于：同步 I/O（如未设 timeout 的 HTTP client）、锁竞争、GC 停顿尖刺。
立即学习“go语言免费学习笔记（深入）”；
- 先检查 GC 情况：
curl "http://host:6060/debug/pprof/gc" | go tool pprof -http=:8081 -，看 pause 时间是否异常 - 对比
/debug/pprof/profile和/debug/pprof/mutex?debug=1，若后者显示高 contention，说明锁是瓶颈 - 火焰图中点击
runtime.mcall→ 右键 “Focus” 查看其上游调用栈，大概率指向net/http或database/sql的阻塞点 - 别迷信“扁平化”火焰图；用
go tool pprof -top先看 top 函数，再决定是否深入火焰图
实际部署时，最常被跳过的一步是验证符号表是否完整——go build 加了 -ldflags="-s -w" 就再也看不到函数名了。这点一旦出错，整个火焰图就只剩 runtime 框架，毫无排查价值。
