必须用blackhole变量或runtime.KeepAlive保留结果，配合b.ReportAllocs()和b.ResetTimer()（顺序为ReportAllocs→ResetTimer→循环→存入blackhole），且初始化在循环外、避免手动赋值b.N。

怎么写一个不被编译器优化掉的 Benchmark 函数

直接写 BenchmarkXxx 但没处理返回值，大概率测出来的是 0 ns/op —— 因为 Go 编译器发现结果没被用，就整个逻辑给删了。

• 必须把被测函数的返回值赋给局部变量，再加一行 _ = result 或 b.ReportMetric(0, "") 防止消除
• 别在循环里反复创建测试输入（比如每次 new 一个 map），否则测的是内存分配而非目标逻辑；提前构造好，放在 for 外面
• 如果函数依赖初始化（如 sync.Pool 首次调用慢、map 第一次写入有扩容开销），要在 for 循环前显式预热：跑 1–2 次再调 b.ResetTimer()
• b.N 是框架自动调节的迭代次数，不是你手动设的；别写 for i := 0; i ，否则统计失效

为什么 -benchmem 和 -count=5 必须一起用

只看 ns/op 容易误判：一个函数快但每轮分配 100KB 内存，GC 压力上来后在线上反而更卡。

• -benchmem 输出的 B/op 和 allocs/op 才反映真实资源开销，尤其对微服务这种长周期进程至关重要
• -count=5 不是“多跑几次取平均”，而是让 benchstat 有足够样本做 Welch’s t-test —— 它判断的是“性能提升是否统计显著”，不是“看起来快了 10%”
• 漏掉 -count 直接比两个单次结果，可能把系统噪声当成优化收益；建议固定用 -count=5 -benchtime=3s，平衡稳定性与耗时

pprof 火焰图里看到 runtime.mallocgc 占比高，下一步该查什么

这不是 GC 本身的问题，而是你的代码在频繁触发堆分配 —— 比如切片没预估容量、结构体指针传参导致逃逸、或 JSON 解析时用了 interface{}。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

• 先用 go tool compile -gcflags="-m -l" 检查关键函数的逃逸分析，重点关注带 ... (moved to heap) 的行
• 对高频路径中的切片操作，确认是否用了 make([]T, 0, N) 预分配；append 无 cap 时双倍扩容拷贝成本极高
• 如果火焰图里 encoding/json.(*decodeState).unmarshal 下沉很深，考虑改用 jsoniter 或预定义 struct 替代 map[string]interface{}
• 别急着加 sync.Pool：Pool 本身有锁开销，只对 >1KB 且生命周期明确的对象才有效；小对象逃逸优先用栈分配优化

线上服务不能停，怎么安全采集 CPU profile

直接跑 pprof.StartCPUProfile 可能卡住请求，尤其在 QPS 过万的网关层。得用信号 + 延迟采样组合技。

立即学习“go语言免费学习笔记（深入）”；

• 启动时注册 os.Signal 监听 SIGUSR1，收到后才开始 StartCPUProfile，避免常驻开销
• 采样时间严格控制在 30s 内（time.AfterFunc(30*time.Second, pprof.StopCPUProfile)），防止阻塞 goroutine 调度
• profile 文件别写本地磁盘——用 bytes.Buffer 拼完直接 HTTP 返回，curl 抓取后离线分析，避免 IO 毛刺影响 SLA
• 千万别在 http.HandlerFunc 里直接调 pprof.Handler 暴露 /debug/pprof/：未授权访问会导致全量 profile 泄露，生产环境必须加鉴权中间件

实际调优中，最常被忽略的是「逃逸分析和切片预分配」这两层——它们不报错、不 panic，但会让 CPU 利用率在 60% 以上持续抖动，而火焰图里只显示为平缓的 runtime 函数占用，容易误判成 GC 问题。