最常见原因是构建时strip了调试符号，导致pprof无法解析函数名而只显示十六进制地址；必须禁用-ldflags="-s -w"，确保二进制含debug_info，并通过file或readelf验证符号存在。
pprof 采集 CPU 数据时为什么看不到函数名？
最常见原因是构建时 strip 了调试符号，go tool pprof 拿不到函数名和行号，只显示一堆 0x456789 地址。这不是 Gin 的问题，也不是 pprof 坏了，而是二进制本身没带符号表。
- 构建命令里不能带
-ldflags="-s -w"，必须清空或显式写成-ldflags="" - 验证方式：运行
file ./your-binary，输出里要有with debug_info；或执行readelf -S ./your-binary | grep debug，有结果才对 - 已构建出 stripped 二进制？删掉重 build，GoLand 或其他 IDE 重跑不会自动修复
Gin 服务如何正确暴露 /debug/pprof 路由？
Gin 默认不注册 net/http/pprof，直接访问 /debug/pprof/ 会 404。你得手动桥接过去，否则所有 pprof 命令都连不上。
- 推荐用
github.com/gin-contrib/pprof：调用pprof.Register(r)即可，默认挂到/debug/pprof - 如果想限制访问，别直接注册到根路由，改用受保护的 Group：
adminGroup := r.Group("/admin", gin.BasicAuth(...))，再调用pprof.RouteRegister(adminGroup, "pprof") - 不依赖第三方包的话，手动桥接：
r.GET("/debug/pprof/*pprof", gin.WrapH(http.DefaultServeMux))，前提是你的代码里确实启动了http.DefaultServeMux（比如另起 goroutine 跑http.ListenAndServe("localhost:6060", nil)）
生成火焰图前必须确认的三个参数组合
火焰图本质是调用栈采样聚合后的可视化，采样方式、时长、目标 profile 类型三者错一个，图就失真——比如把 heap profile 当成 CPU profile 渲染，你会看到一堆内存分配点，但完全看不出谁在吃 CPU。
- CPU 火焰图：用
go tool pprof -http=:1234 http://localhost:8080/debug/pprof/profile?seconds=30，默认 30 秒，别省略?seconds=参数，否则可能只采几秒 - 内存火焰图：用
go tool pprof -http=:1234 http://localhost:8080/debug/pprof/heap，看的是当前堆快照，不是分配速率 - 要导出 SVG：在 pprof web 界面点 “View” → “Flame Graph”，或命令行加
-svg，但注意：需提前装好graphviz（macOS 用brew install graphviz，Linux 用apt install graphviz）
火焰图里扁平宽条 ≠ 性能瓶颈，要看“顶部宽 + 向下延伸深”的组合
新手常误判：看到某个函数占满整行就以为是罪魁祸首。其实关键要看它是否长期处于调用栈顶端（即“顶部宽”），且其子调用是否层层展开（即“向下延伸深”）。Gin 的 c.Next() 和中间件链容易在这里制造假热点。
- 例如
gin.(*Context).Next在火焰图顶部又宽又深？大概率是中间件里做了同步阻塞操作（如未设 timeout 的 HTTP 调用、未用连接池的 DB 查询），而不是 Gin 框架本身慢 - 对比看
runtime.mcall或syscall.Syscall是否频繁出现在深栈底部——这说明卡在系统调用，该查网络、磁盘或锁竞争了 - 若大量
runtime.newobject或runtime.mallocgc出现在中上层，说明业务逻辑在高频分配小对象，优先检查 JSON 序列化、字符串拼接、切片 append 是否可复用或预分配
c.Next() 下面的 3ms 数据库查询。 
