进入交互后

Go 性能优化的正确顺序只有一句话：先让 pprof 告诉你时间花在哪、内存被谁占了，再动手改代码，最后用基准测试验证收益——凭直觉猜瓶颈，十次有九次猜错。

30 秒接入 pprof：标准库自带，不用装任何东西

结论：Go 标准库内置 pprof，只需一次匿名导入加一个 HTTP 监听，就能同时拿到 CPU、堆、协程、锁等六类运行时数据。

import (
    "net/http"
    _ "net/http/pprof" // 匿名导入即注册 /debug/pprof/ 路由
)

func main() {
    go func() { http.ListenAndServe("127.0.0.1:6060", nil) }()
    // 业务启动逻辑
}

注意两点：一是监听地址写 127.0.0.1 或另开内网端口，pprof 端点不鉴权，暴露公网等于把内存镜像送人；二是服务用的是自有 HTTP 框架（比如 gin、echo）时，`net/http/pprof` 注册在 DefaultServeMux 上不会自动生效，需要手动把 `pprof.Index`、`pprof.Profile` 等 Handler 挂到自己的路由上。不方便开端口时，也可以用 `runtime/pprof` 在代码里手动 `StartCPUProfile` / `WriteHeapProfile` 写文件。

抓 CPU 瓶颈：采样时间要够长，看 flat 而不是凭感觉

结论：CPU profile 默认 100Hz 采样，抓取时长低于 10 秒几乎没有统计意义，生产排查建议 30 秒起步。

go tool pprof "http://127.0.0.1:6060/debug/pprof/profile?seconds=30"

(pprof) top        # 按 flat 降序，找自身耗时最多的函数
(pprof) top -cum   # 按累积耗时排序，看调用链总开销
(pprof) list 函数名 # 逐行看源码耗时分布
(pprof) web        # 生成调用图，需本机装 graphviz

理解两个指标是关键：flat 是函数自身消耗的 CPU，cum 是它及其下游调用的总和。结论：定位"谁在烧 CPU"看 flat 排序的 top，判断"哪条链路整体重"看 cum。线上更省事的做法是用 `go tool pprof -http=:8080 http://...` 直接开浏览器看火焰图，横向宽度就是耗时占比，宽条一眼可见。

抓内存瓶颈：先分清"分配多"和"占着不放"

结论：内存问题必须先分型——GC 压力大是分配量问题，看 alloc_space；进程常驻高是持有量问题，看 inuse_space。

go tool pprof http://127.0.0.1:6060/debug/pprof/heap
(pprof) sample_index = alloc_space   # 切到累计分配量
(pprof) top

heap profile 默认展示 inuse_space（采样时刻仍存活的内存），需要看"谁在疯狂制造垃圾"时切到 alloc_space。另外注意 `runtime.MemProfileRate` 默认约 512KB 采样一次，这是统计估算，不是逐字节精确值，别拿它当内存泄漏的唯一证据。

验证是否泄漏最有效的手段是做差：

go tool pprof -base old.heap new.heap

两次快照相减后还持续增长的调用栈，才是真正可疑的泄漏点。常见修复套路：用 `sync.Pool` 复用大对象、初始化 slice 时按预估容量 `make([]T, 0, n)`、拼接字符串用 `strings.Builder`、减少 `[]byte` 与 `string` 之间的无谓转换。

别漏掉 goroutine / block / mutex：延迟高但 CPU 不高时全靠它们

结论：CPU 和内存都正常、但接口延迟仍然偏高时，瓶颈通常是协程泄漏或锁竞争，这时要去看 goroutine、block、mutex 三类 profile。

访问 `/debug/pprof/goroutine?debug=2` 可以直接看到全部协程的完整调用栈，同一条栈上几百个协程卡住，基本就是泄漏。block（阻塞）和 mutex（锁竞争）默认是关闭的，因为采样开销较大，需要显式开启：

runtime.SetBlockProfileRate(1)
runtime.SetMutexProfileFraction(1)

建议只在排查期临时打开，问题定位后关闭，不要长期挂在生产上。

闭环验证：没有数字对比的优化不算优化

结论：任何优化都必须有优化前的基线数据和优化后的对比数据，否则无法判断收益是否真实。

go test -bench=. -benchmem -cpuprofile=cpu.out -memprofile=mem.out ./...
go tool pprof -base cpu.old cpu.new

`-benchmem` 输出的 ns/op、B/op、allocs/op 三个数字，分别对应单次耗时、单次分配字节数、单次分配次数，优化前后对齐看这三项就够了。pprof 是"现场勘查工具"，它只负责告诉你问题在哪，不负责替你修——先量数据、再改代码、后验证，这套流程走顺了，Go 服务的性能问题基本没有玄学。