go-perf 不是 Go 官方工具，也跑不起来
直接说结论：go-perf 并不存在于 Go 生态中，也没有这个工具集。你搜到的可能是拼写混淆（比如把 Linux 的 perf 和 Go 混在一起），或是某个已归档、无人维护的第三方实验项目。Go 官方性能分析链路里压根没有叫 go-perf 的命令或库。
真正能做硬件级性能评估的，是 Linux 内核自带的 perf，配合 Go 编译出的二进制（需保留符号表）使用。误以为有 go-perf 工具，会导致卡在第一步——根本找不到可执行文件。
用 Linux perf 分析 Go 程序要开哪些编译开关
Go 默认编译会 strip 掉调试信息和符号，perf record -g 采样后几乎看不到函数名，只能看到 [unknown] 或地址。必须显式控制构建行为：
- 加
-gcflags="all=-N -l"：禁用内联 + 禁用优化，保留行号和变量信息 - 加
-ldflags="-s -w"—— 别加！这是反向操作，会删掉符号表，perf就废了 - 推荐完整命令：
go build -gcflags="all=-N -l" -o myapp main.go
注意：-N -l 会让二进制变大、运行稍慢，仅用于 profiling 场景，别放进生产构建流水线。
立即学习“go语言免费学习笔记（深入）”；
perf record 采样时为什么看不到 goroutine 栈
perf 是基于 CPU cycle / event 的内核级采样器，它看到的是 OS 线程（pthread）和机器指令，不是 Go runtime 的 goroutine。所以默认 perf report -g 展开的是 runtime.mcall、runtime.park_m 这类调度器函数，而不是你的 handleRequest。
想关联到业务代码，得靠两层映射：
- 确保二进制含符号（上一条已说）
- 用
perf script导出原始样本，再用go tool pprof转换：perf script | go tool pprof myapp - - pprof 能识别 Go 的栈帧标记（通过
runtime.curg._defer等线索），把内核栈“重解释”为 goroutine 栈
跳过 go tool pprof 直接看 perf report，等于只看了半张图。
硬件事件采样（如 cache-misses）对 Go 程序有意义吗
有意义，但解读要小心。例如跑 perf record -e cache-misses ./myapp，出来的热点可能集中在：
-
runtime.mallocgc：说明分配频繁，可能对象逃逸严重 -
runtime.memmove：切片拷贝或接口赋值多，内存带宽打满了 - 你的业务函数本身：才真值得优化
Go runtime 自身大量使用缓存友好的数据结构（如 span、mcentral），但 GC 周期、调度切换、interface{} 装箱都会触发非预期 cache miss。别一看到高 cache-misses 就去改算法——先确认是不是 runtime 开销占大头。
真实瓶颈常藏在「runtime 和业务的交界处」：比如一个 map[string]interface{} 解析 JSON，既触发 GC 又引发大量 cache line 无效。这种地方，perf 能定位，但得结合 go tool trace 和 pprof --alloc_space 交叉验证。
