go-torch不推荐在生产环境直接使用，因其依赖的net/http/pprof默认仅监听localhost、多年未维护导致Go1.20+符号解析失败、容器中缺乏perf权限、采样时长与输出格式不可控。
go-torch 生成 go 网络服务火焰图这件事，现在不推荐直接用——它在生产环境基本不可靠，本地调试也容易卡在路径、权限或符号解析上。
为什么 go-torch 默认连不上你的 Go 网络服务？
go-torch 默认访问 <a href="https://www.php.cn/link/56ecdfc08077e1c1aa0feb4ee9f1bcb7">https://www.php.cn/link/56ecdfc08077e1c1aa0feb4ee9f1bcb7</a>，但绝大多数 Go 网络服务：
- 没有注册
net/http/pprof（忘了 import_ "net/http/pprof"） - 启动的是非默认端口（比如
:6060或:9090），而没改-u参数 - 使用了自定义
http.ServeMux，但没把 pprof 路由显式挂载进去
常见错误现象：
Get "<a href="https://www.php.cn/link/56ecdfc08077e1c1aa0feb4ee9f1bcb7?seconds=30">https://www.php.cn/link/56ecdfc08077e1c1aa0feb4ee9f1bcb7?seconds=30</a>": dial tcp 127.0.0.1:8080: connect: connection refused- 返回 HTML 页面（比如你服务的首页），而不是二进制 profile 数据
- 生成的 SVG 里全是
???或截断函数名（符号表被 strip 或内联干扰）
正确做法是先手动验证端点可用性：
curl -s -o /dev/null -w "%{http_code}" https://www.php.cn/link/f42c61b0473deca6a719dfce6c235d8f —— 应返回 200，且输出是二进制（file profile 显示 data）
go-torch 的 --seconds 参数根本不起作用？
是的。很多用户发现加了 --seconds 5 还是采样 30 秒，原因在于：
-
go-torch会拼接go tool pprof -raw -seconds 5 ...，但旧版go tool pprof（Go 1.18 之前）不支持-raw和-seconds同时使用 - 它实际执行的是
go tool pprof -raw http://...，然后靠 pprof 服务端自己决定采样时长（默认 30 秒） - 更糟的是：Go 1.20+ 已废弃
-raw，go-torch源码未更新，直接报错或静默失败
可靠替代方式：
- 直接构造带
?seconds=5的 URL：go-torch -u '<a href="https://www.php.cn/link/f42c61b0473deca6a719dfce6c235d8f">https://www.php.cn/link/f42c61b0473deca6a719dfce6c235d8f</a>' - 或绕过
go-torch，用原生命令：go tool pprof -svg '<a href="https://www.php.cn/link/f42c61b0473deca6a719dfce6c235d8f">https://www.php.cn/link/f42c61b0473deca6a719dfce6c235d8f</a>' > flame.svg
容器/K8s 里跑 go-torch 为什么总失败？
根本原因就一个：go-torch 在容器里试图调用系统级采样器（Linux 的 perf），但：
- Kubernetes Pod 默认禁用
perf_event_opensyscall（SecurityContext 限制） - 容器镜像里通常没装
perf，也没 Perl（flamegraph.pl依赖） -
go-torch不区分 wall-clock 采样和 kernel-level 采样，硬编码走 perf 路径
安全可行的做法：
- 不在容器内运行
go-torch，改用kubectl exec在 Pod 内直接调用 Go 运行时 profiler：kubectl exec my-app-pod -- curl -s localhost:6060/debug/pprof/profile?seconds=15 | go tool pprof -svg - > flame.svg - 确保服务启动时加了编译参数：
go build -gcflags="all=-l" -ldflags="-s -w" ...（保留符号，禁用内联）
生成的火焰图里函数名全是 runtime.xxx 或 ???
这不是 go-torch 的锅，而是 Go 构建时符号信息丢失导致的。关键点：
-
-ldflags="-s -w"会剥离符号表（减小体积），但火焰图需要函数名 → 必须去掉-s或只留-w -
-gcflags="all=-l"禁用内联，否则深层调用被折叠，热点函数“消失” - 如果用 Docker 多阶段构建，确保 final 镜像里二进制没被 strip 过（比如 Alpine 镜像常自带
strip）
验证方法：
go tool objdump -s "main\.handler" your-binary | head -10 —— 能看到汇编和函数名，才说明符号可用
真正麻烦的是：这些编译选项必须在服务上线前就确定，线上临时重编译几乎不可能。所以火焰图分析本质是个“上线前约定”，不是线上救火工具。
go-torch 的问题不在功能，而在它把一堆脆弱依赖（Perl、perf、pprof 版本、符号表）绑死在一个不再维护的壳里。现在更稳的路径是：用 go tool pprof 直出 SVG，或上 pprof Web UI（go tool pprof -http=:8080 ...）。
