goroutine泄漏比内存泄漏更难发现，因其不触发OOM却导致响应变慢、CPU偏高；需用pprof对比多阶段goroutine数，所有channel操作须配context超时，避免重复启停、误用sync.Pool和channel模拟锁。

goroutine 泄漏比内存泄漏更难发现

Go 的 goroutine 轻量但不自动回收，一旦启动后阻塞在 select、channel 接收或未关闭的 http.Server 上，就会持续占用栈内存和调度器资源。这类泄漏往往不会触发 OOM，却会让服务响应变慢、CPU 持续偏高。

• 用 pprof/goroutine 快照对比：启动前、压测后、空闲 5 分钟后再抓一次，观察数量是否回落
• 所有带超时的 channel 操作必须配 context.WithTimeout 或 context.WithCancel，不能只靠 time.After
• 启动长期运行的 goroutine（如监听配置变更）前，务必检查是否已有同逻辑实例在跑，避免重复启停导致旧 goroutine 悬空

sync.Pool 在高频并发下可能适得其反

sync.Pool 本意是复用临时对象减少 GC 压力，但在高并发短生命周期场景（如每请求新建一个 bytes.Buffer），它反而会因内部锁和跨 P 清理逻辑引入竞争和延迟。

• 仅当对象构造开销大（如 regexp.Compile 结果）、且生命周期明显长于单次请求时才考虑 sync.Pool
• 避免把含指针或闭包的结构体放入 sync.Pool，GC 不保证其引用关系安全，可能引发 panic 或数据污染
• 测试时对比 GODEBUG=gctrace=1 下的 GC 次数与 p99 延迟，若延迟上升而 GC 次数下降，说明 sync.Pool 在拖慢关键路径

不要用 channel 模拟锁，尤其在写密集场景

用带缓冲的 channel（如 make(chan struct{}, 1)）做互斥，代码看似简洁，但实际会绕过 Go 调度器的公平性保障，容易导致 goroutine 饿死或上下文切换激增。

• 写操作频繁时，sync.Mutex 的自旋+休眠策略比 channel 更高效；读多写少可直接上 sync.RWMutex
• 若需“带超时的获取锁”，应调用 mutex.TryLock()（需第三方库如 github.com/cespare/xxhash 不提供，推荐 go.uber.org/atomic 或自己封装）而非 select { case
• channel 更适合做“事件通知”或“任务分发”，比如 worker pool 中的 jobs chan *Task，而不是保护某个字段的读写

context.WithCancel 的 cancel 函数必须显式调用

很多设计模式（如 pipeline、fan-in/fan-out）依赖 context 传递取消信号，但开发者常忽略：父 context 被 cancel 后，子 context 不会自动触发子 cancel 函数——除非你手动调用它。

• 每次调用 context.WithCancel 后，必须确保在业务逻辑结束时执行返回的 cancel()，常见位置是 defer cancel() 或 defer 匿名函数中判断状态后调用
• 不要把 cancel 函数传给不受控的第三方库，它可能被缓存或异步调用，造成提前 cancel
• 在 HTTP handler 中，req.Context() 的 cancel 已由 net/http 管理，你不该再调用它的 cancel；但你自己派生的子 context（如 ctx, cancel := context.WithTimeout(req.Context(), 3*time.Second)）必须自己管

func handleRequest(w http.ResponseWriter, r *http.Request) {
    // 正确：子 context 的 cancel 必须由当前函数负责
    ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second)
    defer cancel() // 关键

    select {
    case result := <-doWork(ctx):
        w.Write(result)
    case <-ctx.Done():
        http.Error(w, "timeout", http.StatusRequestTimeout)
    }
}