goroutine泄漏比性能差更致命，因持续增长会导致内存暴涨和OOM；需用pprof或runtime.NumGoroutine()排查，修复须确保退出路径、配对channel操作、善用context。
goroutine 泄漏比性能差更致命
很多开发者一上来就调 runtime.GOMAXPROCS 或压测吞吐，却忽略最常发生的 goroutine 泄漏。一旦协程持续增长不回收，内存暴涨、GC 压力陡增，程序直接 OOM——这比“慢”更早杀死服务。
排查方法很简单：pprof 抓取 /debug/pprof/goroutine?debug=2，看是否有大量处于 select 阻塞、chan receive 或 syscall 状态的 goroutine；更轻量的方式是用 runtime.NumGoroutine() 定期打点，观察是否随请求量线性或指数增长。
- 常见泄漏点：未关闭的 channel 导致
range永不退出；time.AfterFunc里启动 goroutine 但没绑定生命周期；HTTP handler 中启 goroutine 处理异步逻辑，但 handler 返回后 goroutine 仍在运行 - 修复原则：所有 goroutine 必须有明确退出路径，优先用
context.Context控制取消；channel 操作必须配对（发送方 close，接收方检查ok）；避免在无上下文约束的闭包中启动长期存活的 goroutine
channel 使用不当会拖垮吞吐
channel 是 Go 并发的标志性抽象，但不是万能缓冲区。默认无缓冲 channel 的每次收发都需双方 goroutine 同时就绪，本质是同步点；而大容量缓冲 channel 若写入远快于读取，会吃光内存。
典型反模式：make(chan int, 10000) 当队列用，却不控制生产者速率；或在 hot path 上频繁 len(ch) 判断长度（非原子操作，且触发锁竞争）。
立即学习“go语言免费学习笔记（深入）”；
- 高吞吐场景下，优先考虑无缓冲 channel + 显式超时控制（
select+time.After），避免堆积 - 若必须缓冲，容量应基于最大预期积压量 + 超时丢弃策略（例如用
select配default分流过载请求） - 避免在循环中反复创建 channel；复用 channel 时注意其方向（
chan /）和关闭状态，已关闭的 channel 再 send 会 panic
sync.Pool 不是缓存，是对象复用工具
很多人把 sync.Pool 当作通用内存缓存，结果发现 GC 压力没降、命中率还低。它本质是「按 P 局部缓存 + GC 前清空」的临时对象池，只适合生命周期短、创建开销大的对象（如 []byte、bytes.Buffer、自定义结构体）。
错误用法包括：存入带指针的长生命周期对象（导致 GC 无法回收关联内存）、从 Pool 取出后长期持有、或用它替代 map 做业务缓存。
- 正确姿势：在函数入口
Get()，使用完立刻Put()；Put()前确保对象字段已重置（尤其切片底层数组、指针字段） - 注意
sync.Pool的New函数只在 Get 无可用对象时调用，不能依赖它做初始化逻辑（比如注册回调） - 实测有效场景：JSON 解析中的
bytes.Buffer、HTTP body 读取的临时[]byte缓冲、Protobuf 序列化用的proto.Buffer
避免在 goroutine 中滥用 defer
defer 看似优雅，但在高频 goroutine 场景下，每个 defer 调用都会分配一个 _defer 结构并链入 goroutine 的 defer 链表。当 goroutine 数量达万级、每个又带 2–3 个 defer，内存和调度开销不可忽视。
尤其常见于日志、监控埋点等“看起来无害”的地方：比如每个 handler goroutine 都 defer metrics.Record()，实际成了性能黑洞。
- 高频路径上，用显式调用替代
defer（如mu.Lock(); defer mu.Unlock()改为mu.Lock(); ...; mu.Unlock()） - 若必须用
defer，合并多个逻辑到单个函数中（减少 defer 节点数），或用if err != nil { cleanup() }替代 - 注意
defer在循环内声明会导致每次迭代都注册一个延迟调用，务必移出循环
