Golang 从入门到放弃 -0x1A
性能分析与 pprof：先找证据，再定位 CPU、内存和等待热点。
很多人第一次碰到性能问题时，第一反应是开始猜。猜数据库慢、猜网络慢、猜 Go GC、猜容器限制、猜云厂商抽风。猜不是完全没用，但如果一直靠猜，效率往往低得惊人。性能排查最重要的，不是直觉，而是证据。
先问一个问题：到底慢在哪
性能问题大体可以先粗暴分三类：
- CPU 忙不过来
- 内存压力大
- I/O、锁、网络、数据库之类的等待太多
连“慢在哪”都没分清，就开始优化，最后很容易把力气花在最不该花的地方。
pprof 先混个脸熟
Go 自带的 pprof 是非常实用的一套分析工具。最常见的接入方式是挂到 HTTP 服务上。
import _ "net/http/pprof"
go func() {
log.Println(http.ListenAndServe("localhost:6060", nil))
}()起来之后，就能通过浏览器或命令行抓 profile 了。
看 CPU
go tool pprof http://127.0.0.1:6060/debug/pprof/profile?seconds=30这个命令会采 30 秒 CPU profile。你最需要关注的，是热点函数到底是谁，而不是凭印象认定“肯定是某个看起来复杂的函数”。
看内存
go tool pprof http://127.0.0.1:6060/debug/pprof/heap如果你怀疑内存涨得离谱、GC 频繁、对象分配过多，这个就很有帮助。
常见误区
- 还没测，先上缓存
- 还没定位，先并发改造
- 看到某段代码丑，就认定它慢
- 把压测结果和线上表现混为一谈
优化最怕的不是改不动，而是改了半天，最后证明你在优化错误目标。
性能优化通常从最贵的地方下手
真实项目里，最值钱的优化往往不是把某个小循环省 2ns，而是：
- 减少无意义的数据库查询
- 避免重复序列化和反序列化
- 减少外部接口调用次数
- 降低锁冲突和串行等待
也就是说，业务层的大头常常比语法层的小聪明更重要。
小结
这一章主要想传达一个思路：
- 性能排查先找证据，再谈优化。
pprof是 Go 里非常值得掌握的工具。- CPU、内存、等待，先分清是哪类问题。
- 很多最有效的优化，其实发生在业务设计层。
下一章我们开始做整个系列的收束，聊一个小项目到底该怎么拆、怎么落地，而不是只会在脑子里觉得“我懂了”。