goroutine泄漏比cpu高更难发现，表现为服务变慢、内存缓慢上涨、gc频次升高但cpu profile无热点；一旦runtime.numgoroutine()随时间线性或指数增长即可判定泄漏。
goroutine 泄漏比 CPU 高更难发现
服务跑着跑着变慢、内存缓慢上涨、GC 频次越来越高，但 pprof 的 CPU profile 看不出明显热点——这八成不是“慢”，是协程在偷偷堆积。一旦 runtime.NumGoroutine() 随时间线性或指数增长，基本可判定泄漏。
- 最直接的排查方式：访问
/debug/pprof/goroutine?debug=2，重点看堆栈里是否大量卡在select、chan receive、time.Sleep或net/http.readLoop - 常见泄漏点：
for range读未关闭的chan；HTTP handler 中启了 goroutine 做异步调用，但 handler 返回后它还在等 response；time.AfterFunc启动的 goroutine 没绑定context生命周期 - 修复核心原则：确保每个 goroutine 都有明确退出路径；channel 使用必须配对（send/recv + close）；所有 I/O 操作必须带
context.Context超时控制
别乱设 buffer 大小，channel 不是缓存池
把 make(chan int, 10000) 当成“抗压保险丝”，结果延迟飙升、内存吃紧、下游一卡整个 channel 就积压满——这不是撑住了流量，是掩盖了消费瓶颈。
- 无缓冲 channel（
make(chan int)）本质是同步点，适合信号通知、等待完成等强协作场景 - 带缓冲 channel 的容量应基于「最大容忍延迟」反推：若消费者平均处理耗时 5ms，你允许单点最多积压 200ms，那 buffer 设为 40 更合理，而非拍脑袋填 1000
- 大 buffer 容易掩盖真实问题：比如下游 DB 查询变慢，上游照常狂塞，最终 OOM 前都看不出异常
sync.Pool 不是万能对象池，用错反而拖慢
把 sync.Pool 当成通用缓存，往里塞 map、含指针的大 struct、甚至长期存活的连接对象，轻则 GC 无法回收关联内存，重则引发数据污染或伪共享，性能比不用还差。
- 只适合复用「构造开销大 + 生命周期短」的对象，例如
*bytes.Buffer、*json.Decoder、预分配的[]byte切片 - 每次
Get()后必须手动清零或重置字段（如调用buf.Reset()），否则残留数据可能被下一个请求误用 -
Put()前建议判断大小：过大的切片（如cap(s) > 1024）不归还，避免池内长期驻留大内存块 - 不要在
init()里预热 Pool，Go 1.21+ 已优化首次 Get 行为，预热反而干扰 GC 统计
HTTP 客户端不设超时，等于给 goroutine 发长期签证
一个没设 context 超时的 http.Client.Do()，遇到慢下游或网络抖动，就会让 goroutine 卡在 readLoop 里不动，既不失败也不释放，积少成多直接拖垮实例。
- 永远用
context.WithTimeout()包裹请求，而不是依赖Client.Timeout（它无法中断 DNS 解析或 TLS 握手阻塞） - 不同链路设不同超时：认证服务可设 800ms，下游核心 API 设 2s，非关键埋点接口设 300ms 并快速降级
- 全局复用
http.Client，自定义Transport时务必配置：MaxIdleConns、MaxIdleConnsPerHost（建议 ≥100）、IdleConnTimeout（建议 30s）
性能优化真正的难点，从来不在“怎么加功能”，而在“怎么安全地删东西”——删掉不必要的 goroutine、删掉没用的 buffer、删掉没清理的 pool 对象、删掉没超时的 HTTP 调用。这些“删”的动作，恰恰是最容易被忽略的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
