性能优化须先用 pprof 定位瓶颈，再针对性优化：CPU 热点、内存分配、goroutine 泄漏；基准测试需防编译器优化、测 GC 压力、多规模多并发验证；慎用 lo 库与 sync.Pool，避免盲目池化和反射开销。
pprof 没跑就动手改代码，90% 是白忙
性能优化的第一步不是重写逻辑，而是确认瓶颈在哪。很多人一看到接口慢，立刻去换 strings.Builder、加 sync.Pool、重构 for 循环，结果 profile 一看：95% 时间花在 http.Client.Do 上——根本是没复用连接池。
必须先暴露 pprof 接口并抓真实流量数据：
-
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30看 CPU 热点 -
go tool pprof http://localhost:6060/debug/pprof/heap看内存分配大户 -
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2查 goroutine 泄漏
注意：别信直觉。比如 fmt.Sprintf 看似重，但 profile 显示只占 0.3%，而 json.Unmarshal 占 68% —— 那就该预分配 json.RawMessage 或换 jsoniter，不是动字符串。
基准测试里 ns/op 低 ≠ 上线快，MB/s 高 ≠ 服务稳
ns/op 是平均单次耗时，极易被编译器优化“骗过”：中间变量没被使用，整个计算可能被删掉。更危险的是，它完全不反映 GC 压力和毛刺。
立即学习“go语言免费学习笔记（深入）”；
实操要点：
- 用
runtime.KeepAlive或全局变量兜住结果，防止优化干扰：blackhole = computeSomething()+runtime.KeepAlive(blackhole) - 初始化开销（如
make([]byte, 1e6)）必须放在b.ResetTimer()之后，否则污染计时 - 务必开
b.ReportAllocs()，否则allocs/op默认为 0，你会误以为没分配内存 - 小数据测得再漂亮也没用，要交叉验证不同规模：
-benchmem -benchtime=5s+ 多组输入长度
并发测试更要小心：go test -bench=. -cpu=1,2,4,8 才能看出扩展性；被测函数内部必须等所有 goroutine 结束，否则计时提前收尾。
滥用 lo 库函数导致内存暴涨、速度变慢
像 lo.Filter、lo.Map、lo.FlatMap 这类工具函数，在小数据上写起来爽，但一到 10 万级数据，问题就暴露了：预分配策略激进、反射开销大、闭包捕获变量引发堆分配。
典型陷阱：
-
lo.Filter总是make([]T, 0, len(collection))，过滤率 20% 时浪费 80% 内存 → 改用make([]T, 0)+append -
lo.Map在 Go 1.21 前依赖反射，每次调用有两次类型断言 → 改用索引 for 循环，甚至直接赋值字段：users[i].ID = rawData[i].ID -
lo.ForEach嵌套时闭包捕获外层变量（如i），强制堆分配 → 改用原生双层for，零分配
不是不能用 lo，而是得清楚它在哪种规模、哪种结构下会掉队。上线前跑一次 benchstat 对比，比凭经验靠谱得多。
sync.Pool 用错地方，反而加重 GC
sync.Pool 不是缓存，也不是通用对象池。它的核心价值是“短生命周期 + 高频创建 + 结构体/切片大小稳定”，比如 HTTP 请求中的临时 buffer、JSON 解析用的 []byte、中间件里的 *RequestCtx。
常见错误：
- 池化长生命周期对象（如数据库连接、全局配置），导致对象滞留、内存无法回收
- 初始化
New函数后，Get出来没重置关键字段，下次Put回去时带着脏状态污染其他请求 - 对小结构体（如
struct{a,b int}）盲目池化，逃逸分析本可栈分配，结果硬推到堆上
正确姿势：只池化明确高频且逃逸的资源；Get 后强制清空字段（如 v.field = ""）；用 runtime.ReadMemStats 对比 NumGC 和 PauseNs 确认 GC 压力是否真下降。
最易被忽略的一点：所有优化都得建立在真实 profile 和可控 benchmark 基础上。笔记本电源模式切换、后台 Docker 调度、甚至 go mod tidy 拉错版本，都可能让 ns/op 波动 ±30% —— 别把噪声当信号。
