go性能问题多因gc停顿、goroutine泄漏或高频堆分配，需用pprof抓真实profile；pprof 404因nil handler或路由框架拦截，应显式注册或改用runtime/pprof手动采样；heap profile须对比两次强制gc后的快照查净增长；goroutine泄漏需debug=2获取全量栈；mallocgc高表明gc压力大，应减少隐式分配并预分配复用；务必建立基准profile作为性能标尺。
Go程序跑得慢，八成不是算法问题，而是GC停顿、goroutine泄漏或高频堆分配在拖后腿。别急着重写逻辑，先用pprof抓真实 profile 数据——这是唯一能绕过“我觉得是……”陷阱的路径。
pprof HTTP 接口启用后访问 404？
常见错误现象：导入 _ "net/http/pprof" 并启动了 http.ListenAndServe("localhost:6060", nil)，但访问 http://localhost:6060/debug/pprof/ 返回 404。
- 根本原因：
nil作为 handler 时，只注册了/debug/pprof/路由，但默认 mux 不处理根路径以外的请求；若你启用了自定义路由（如 Gin、Echo），它会拦截所有请求，导致 pprof 路由失效 - 正确做法：显式注册 pprof 到你的路由框架中——Gin 示例：
r.GET("/debug/pprof/*pprof", gin.WrapH(http.DefaultServeMux))；Echo 示例：e.Any("/debug/pprof/*", echo.WrapHandler(http.DefaultServeMux)) - 更稳妥方式（尤其生产）：改用
runtime/pprof手动写文件，避免暴露 HTTP 接口，例如在 SIGUSR1 信号中触发pprof.WriteHeapProfile(f)
heap profile 看不出内存泄漏？
常见错误现象：采集 /debug/pprof/heap 后用 top 查到 json.Marshal 占用高，但优化后内存仍持续上涨。
- 关键遗漏：默认 heap profile 只反映“当前已分配且未被 GC 回收”的对象（inuse_space），但泄漏往往体现在“累计分配量”（allocs）或“存活对象增长趋势”上
- 必须操作：对比两次采样 —— 先执行
curl -s "http://localhost:6060/debug/pprof/heap?gc=1" > heap1.pb.gz（强制 GC 后快照），压测一段时间后再采heap2.pb.gz，然后用go tool pprof -base heap1.pb.gz heap2.pb.gz查净增长 - 注意参数：
?gc=1强制触发 GC 再采集，否则可能看到大量可回收但尚未回收的对象，干扰判断
goroutine 数量暴涨但 top 显示没几个？
常见错误现象：ps aux | grep myapp 显示 RSS 持续上涨，go tool pprof http://localhost:6060/debug/pprof/goroutine 的 top 却只列出几十个 goroutine。
- 真相：默认
/debug/pprof/goroutine只返回状态为running或runnable的 goroutine；大量泄漏的 goroutine 实际卡在chan receive、select或semacquire上，被过滤掉了 - 必加参数：
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2——debug=2返回全量 goroutine 栈，含阻塞/休眠状态 - 重点关注：输出中反复出现的
runtime.gopark+chan receive或sync.runtime_SemacquireMutex，配合代码检查 channel 是否未关闭、context 是否未 cancel、锁是否未释放
CPU profile 显示 runtime.mallocgc 占比过高
常见错误现象：火焰图里 runtime.mallocgc 或 runtime.gcBgMarkWorker 占 CPU 时间超 30%，但业务函数没几个热点。
- 说明问题本质是 GC 压力，不是计算瓶颈；此时优化任意业务函数都收效甚微
- 验证方式：在代码中插入
var ms runtime.MemStats; runtime.ReadMemStats(&ms); log.Printf("GC: %d, PauseTotalNs: %v", ms.NumGC, ms.PauseTotalNs)，观察压测中 GC 频次和停顿总时长是否激增 - 典型诱因：
fmt.Sprintf、strings.Builder.String()、map[string]interface{}构造、JSON 序列化等隐式分配；应替换为strconv.AppendInt、零分配拼接、预分配bytes.Buffer或sync.Pool复用结构体 - 注意陷阱：
sync.Pool.Put前未清空字段（如s = s[:0]、clear(m)）会导致脏数据复用，反而加剧逃逸和分配
最常被跳过的一步：不对比基线。上线前没跑过 go test -bench=. 和 go tool pprof 基准 profile，就等于没建立性能标尺——后续所有“变快了”或“变慢了”的判断，都是空中楼阁。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
