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 接入本地开发流程，跑三次真实请求、看一眼火焰图，剩下的事就清晰了。 
