pprof 是性能优化的必选项，必须先用 go tool pprof 定位 CPU、内存、goroutine 瓶颈，再针对性优化；盲目改代码90%是浪费时间。

pprof 不是可选项，是必选项——没跑过 go tool pprof 就动手改代码，90% 的“优化”都在浪费时间。

先看瓶颈，别猜热点

新手最容易犯的错：一上来就重写 for 循环、换 strings.Builder、加 sync.Pool。但实际可能 95% 时间花在数据库连接上，或者 HTTP 客户端没复用 http.Transport。

• 必须先暴露 profile 接口：

  import _ "net/http/pprof"
  
  func main() {
      go func() {
          log.Println(http.ListenAndServe("localhost:6060", nil))
      }()
      // your app
  }

• 跑完真实请求后，立刻抓数据：
  — CPU 瓶颈：go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30
  — 内存分配热点：go tool pprof http://localhost:6060/debug/pprof/heap
  — goroutine 泄漏：go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2
• 别信直觉。比如 fmt.Sprintf 看似慢，但 profile 显示它只占 0.3%，而 JSON 解析占 68% —— 那就该换 jsoniter 或预分配 json.RawMessage，不是去动字符串拼接。

从构建和测试开始省时间

开发阶段的“性能”首先是人等得少。Golang 编译快，但默认配置下，频繁 go test 或 go build 仍会卡顿，尤其模块多、依赖深时。

• 确保环境变量生效（加到 .zshrc 或 .bashrc）：

  export GOPROXY=https://goproxy.cn
  export GOCACHE=$HOME/.cache/go-build
  export GOMODCACHE=$HOME/.cache/go-mod

• 测试提速三件事：
  — 独立测试加 t.Parallel()（仅限无共享状态）
  — 公共初始化提到 TestMain 里，避免每个测试都连 DB / 启 HTTP server
  — 跑局部测试用 go test -run="^TestLogin$" -v，别总 go test ./...
• 构建时加 -ldflags="-s -w"，链接阶段快 20%+，二进制小 30%，且不影响调试（调试用 dlv 本身不依赖符号表）。

高频分配场景，优先套 sync.Pool 和预分配

不是所有对象都值得池化，但以下两类几乎必赢：
— 短生命周期的切片/缓冲区（如 HTTP body 读取、JSON 解析临时 buf）
— 结构体指针（如 *User, *RequestCtx），尤其在中间件或 handler 中高频 new

• 错误示范：

  func handle(r *http.Request) {
      buf := make([]byte, 4096) // 每次请求都 malloc
      r.Body.Read(buf)
  }

• 正确写法：

  var bufPool = sync.Pool{
      New: func() interface{} { return make([]byte, 4096) },
  }
  
  func handle(r *http.Request) {
      buf := bufPool.Get().([]byte)
      defer bufPool.Put(buf)
      r.Body.Read(buf)
  }

• 注意陷阱：
  — sync.Pool 不保证对象复用，GC 时会清空，别存带状态的对象（如已部分填充的 map）
  — slice 预分配比池更轻量：make([]int, 0, 100) 比 make([]int, 100) 少一次初始化开销

别碰编译器内联、汇编、unsafe —— 除非你真看到 pprof 里某函数占 40%+

新手常被“内联能去函数调用开销”吸引，但 Go 编译器自己会做大部分内联决策。手动加 //go:noinline 或 //go:inline 反而容易破坏逃逸分析，导致更多堆分配。

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

• 真正该关注的“底层优化”只有三个：
  — bytes.Buffer / strings.Builder 替代 + 拼接字符串（string 是不可变的，+ 每次都新 alloc）
  — 用 map[string]struct{} 代替 map[string]bool 节省内存（struct{} 占 0 字节）
  — 接口值比较用 reflect.DeepEqual 前先判指针相等：if a == b { return true }（避免反射开销）
• 如果 profile 显示某个函数确实 hot，优先考虑算法降复杂度（比如 O(n²) 改 O(n log n)），而不是抠那几纳秒的调用跳转。

真正卡住新手的，从来不是“不知道怎么优化”，而是“不知道现在哪里慢”。把 pprof 接入本地开发流程，跑三次真实请求、看一眼火焰图，剩下的事就清晰了。

https://www.php.cn/faq/1972057.html