goroutine泄漏比CPU高更难发现，表现为goroutine数持续上涨、内存缓慢增长、GC压力大；sync.Pool非万能缓存，应仅复用构造开销大且生命周期短的对象；channel缓冲区需按最大容忍延迟设定，避免掩盖瓶颈；pprof分析须结合MemStats与gcstoptheworld诊断GC问题。
goroutine 泄漏比 CPU 高更难发现
很多同学一看到 top 里 Go 进程 CPU 占用高，就急着去 profile pprof 的 cpu profile，结果发现热点函数其实很“正常”——真正的问题是 goroutine 数量持续上涨，内存缓慢增长，GC 压力变大。这种泄漏不触发 panic，但会让服务在数小时或数天后变得卡顿甚至 OOM。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 定期用
runtime.NumGoroutine()打点监控，和 Prometheus 指标对齐； - 查泄漏最直接的方式是抓取
/debug/pprof/goroutine?debug=2，看堆栈里有没有大量处于select、chan receive或time.Sleep的 goroutine 卡在同一个调用点； - 常见泄漏场景：忘记 close channel、
for range读未关闭的 channel、http.Client调用未设置Timeout导致 goroutine 卡在readLoop； - 别依赖
defer cancel()在长生命周期 goroutine 里做清理——cancel 后 context.Done() 关闭，但 goroutine 本身未必退出。
sync.Pool 不是万能缓存，用错反而拖慢性能
sync.Pool 的设计目标是复用临时对象、减少 GC 压力，不是替代 map 或 cache。滥用它（比如塞进大对象、长期存活对象、或高频 Put/Get 小对象）会导致内存碎片、伪共享、甚至比 new 更慢。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 只放“构造开销大 + 生命周期短”的对象，比如
*bytes.Buffer、*json.Decoder、自定义结构体指针； - 避免在 Pool 中存带指针的大型结构体（如含
[]byte的 struct），因为 GC 无法回收其底层内存，Pool 会不断膨胀； - 注意
Get()返回值可能为 nil，必须判空并初始化； - 不要在
init()或包级变量里预热 Pool——Go 1.21+ 已优化首次 Get 性能，预热反而干扰 GC 计算； - 压测时对比
GODEBUG=gctrace=1下的 GC 次数和堆增长，比单纯看 QPS 更能判断 Pool 是否起效。
channel 缓冲区大小不是越大越好，尤其在背压场景
很多人以为设个大 buffer（比如 make(chan int, 10000)）就能“撑住流量”，结果发现延迟飙升、内存暴涨、下游消费不及时时数据积压严重，甚至掩盖了真正的瓶颈。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 无缓冲 channel（
make(chan int)）适合同步协作（如信号通知、等待完成），有明确生产/消费节奏； - 缓冲 channel 应基于“最大容忍延迟”反推：如果消费者平均处理耗时 10ms，你允许最多积压 100 个任务，那 buffer 设为 100 是合理的；
- 用
len(ch)监控积压程度，配合 metrics 告警（比如 >80% buffer 满就告警）； - 避免在 HTTP handler 里往大 buffer channel 无节制 send——这相当于把请求队列从 net/http 移到你的 channel，没解决根本问题，还绕过了 http.Server 的
MaxConnsPerHost等保护机制。
pprof 分析必须结合 runtime.MemStats 和 GODEBUG=gcstoptheworld=1
单看 go tool pprof 的 heap profile 容易误判：比如看到大量 runtime.mallocgc 占比高，第一反应是“内存分配太多”，但实际可能是 GC 频繁触发（比如 HeapInuse 涨得快但 HeapAlloc 并不高），或者 STW 时间过长导致吞吐下降。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每次采集 pprof 前，先打一次
runtime.ReadMemStats(&ms)，记录ms.NextGC、ms.NumGC、ms.GCCPUFraction； - 怀疑 GC 成为瓶颈时，加环境变量
GODEBUG=gcstoptheworld=1运行，观察是否 STW 时间显著拉长（>10ms 要警惕）； - 对比 cpu profile 和 trace profile：
go tool trace里重点看 “Goroutines” 和 “Network blocking” 视图，常能发现 goroutine 卡在系统调用或锁上，而非代码逻辑； - 别只看 top3 函数——用
pprof -http=:8080进入交互界面，点击函数名钻进调用树，看是不是某个第三方库的 sync.Mutex.Lock 占了大头。
并发调优最麻烦的从来不是“怎么加 goroutine”，而是“怎么让 goroutine 安静地退出”和“怎么让它们不互相踩内存”。越想压榨性能，越要盯紧 runtime 的反馈，而不是只信自己写的 benchmark。
