接口响应慢主因常是内存分配、GC停顿或阻塞I/O，应优先用pprof分析CPU、heap和goroutine，定位高频分配、goroutine阻塞及未设超时的外部调用等问题。
接口返回慢，90%以上情况不是代码逻辑复杂，而是内存分配、GC停顿或阻塞I/O在拖后腿——先抓pprof堆和CPU profile，别急着改业务逻辑。
用 pprof 快速定位真实瓶颈
很多开发者一上来就怀疑数据库或网络，但实际可能是某次 json.Marshal 在高频请求中反复分配内存，触发了频繁GC。pprof 能直接告诉你哪行代码在“吃”资源。
- 启动服务时加一行：
import _ "net/http/pprof"，再起个 debug 服务：go func() { http.ListenAndServe("localhost:6060", nil) }() - 压测时采集 30 秒 CPU 数据：
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30，进交互模式后输top看耗时最高的函数 - 重点看
heap分配：go tool pprof http://localhost:6060/debug/pprof/heap，关注alloc_space高的函数——比如fmt.Sprintf、strings.ReplaceAll或未预分配的make([]byte, 0) - 别只信火焰图；用
list 函数名查看具体哪一行在分配，比如发现json.Marshal占比高，就得考虑换jsoniter或改用流式json.Encoder.Encode
检查 Goroutine 是否卡在 I/O 或锁上
响应慢常表现为 P99 延迟突增，但 CPU 使用率不高——这往往是 Goroutine 在等数据库、Redis 或 channel，而不是在跑 CPU。
- 访问
http://localhost:6060/debug/pprof/goroutine?debug=2，看有没有成百上千个 goroutine 停在chan receive或semacquire（说明被锁或 channel 阻塞） - 所有外部调用必须带
context.Context：比如db.QueryContext(ctx, ...)、http.DefaultClient.Do(req.WithContext(ctx))，并设好超时（context.WithTimeout(r.Context(), 500*time.Millisecond)） - 避免在 handler 里用
time.Sleep、os.ReadFile或无 context 的db.Query，这些会直接挂起 goroutine - 数据库连接池没配？默认是无限开连，可能耗尽 DB 连接数导致后续请求排队：
db.SetMaxOpenConns(20)、db.SetMaxIdleConns(10)是合理起点
警惕隐式内存分配和接口动态调度
Go 的接口调用本身不慢，但在每毫秒调用数百次的热路径里，查 itab 的间接跳转 + 频繁分配小对象，会叠加出可观延迟。
立即学习“go语言免费学习笔记（深入）”；
- 日志拼接别用
log.Printf("id=%d, name=%s", u.ID, u.Name)——每次都会生成新字符串；改用bytes.Buffer或结构化日志库（如zerolog）的字段写入方式 - 循环里别反复
make([]T, 0)，预估容量：make([]T, 0, 16)；JSON 解析时复用json.Decoder实例，或用sync.Pool缓存临时结构体指针 - 如果某个接口（如
Validator）实现固定且只有一种，别为了“解耦”强套接口；直接传*UserValidator调用方法，省掉一次动态分发 - JWT 解析中间件里反复
json.Unmarshal到map[string]interface{}？缓存这个 map 到sync.Pool，Put 前记得清空字段，否则数据会污染
真正难排查的，往往不是单点慢，而是多个小开销叠加：一次未设超时的 Redis 查询 + 一次未复用的 buffer 分配 + 一个没关的 defer 日志句柄——它们各自只慢几十微秒，但串在一起就让响应从 20ms 拉到 300ms。pprof 不是“用一次就完事”的工具，得在压测流量下持续采样，盯住 PauseTotalNs 和 goroutine 数量变化，才能揪出那个沉默的拖累者。
