goroutine切换开销低，真正瓶颈是调度点触发、内存分配和GC压力；应优先用sync.Mutex而非unbuffered channel限流，善用sync.Pool复用对象并避免泄漏。

为什么 goroutine 切换开销其实不来自“切换”本身

Go 的 goroutine 切换开销被高估了——它不是传统线程上下文切换（寄存器+栈+TLB 刷新），而是协作式调度下的栈跳转，实际成本极低（几十纳秒）。真正拖慢并发性能的，是 runtime.gosched()、channel 阻塞、netpoll 等触发的调度点，以及频繁的 mallocgc 和栈扩容。

• goroutine 创建/销毁比切换更贵（需分配栈、初始化 g 结构体）
• 阻塞在 select 或未缓冲 chan 上时，会真实挂起并让出 P，但这是必要行为，不是“开销”，而是设计取舍
• 大量小 goroutine + 频繁 channel 通信 → 内存分配压力 + 调度器竞争 + GC 压力上升

用 sync.Pool 缓冲高频 goroutine 生命周期

避免每次请求都 go func() {...}()，尤其在 HTTP handler 或循环中。改用复用机制控制 goroutine 数量和资源生命周期。

var workerPool = sync.Pool{
    New: func() interface{} {
        return &worker{done: make(chan struct{})}
    },
}
func getWorker() worker {
w := workerPool.Get().(worker)
w.reset() // 清理状态
return w
}
func putWorker(w *worker) {
workerPool.Put(w)
}

• sync.Pool 不保证对象一定复用，GC 会清理；适合短生命周期、创建开销大的对象
• 不要把含闭包或外部引用的函数塞进 Pool（易导致内存泄漏）
• 如果 worker 内部持有 http.ResponseWriter 或 *bytes.Buffer，必须显式 reset，否则脏状态污染后续使用

慎用 unbuffered channel 替代 mutex，它可能更重

常见误区：用 chan struct{} 控制并发数，以为比 sync.Mutex 更“Go 风格”。但 unbuffered channel 的 send/receive 是同步阻塞点，每次都要进入调度器判定是否就绪，而 sync.Mutex 在无竞争时是纯用户态原子操作（fast path）。

• 无竞争下 sync.Mutex.Lock() ≈ 10ns；ch ≈ 100–300ns（含调度判定）
• 若只是保护一段临界区（如更新 map），优先用 sync.RWMutex 或 sync.Map
• 只有需要解耦生产/消费节奏、或天然有等待语义（如任务分发）时，才用 channel

用 GOMAXPROCS 和 pprof 定位真实瓶颈

盲目调大 GOMAXPROCS 不会减少切换，反而可能加剧 OS 线程争抢和 cache line bouncing。关键看 go tool trace 中的 “Scheduler latency” 和 “Goroutines” 图谱。

• 运行时加 -gcflags="-m" 看逃逸分析，避免 goroutine 捕获大对象导致堆分配
• go tool pprof -http=:8080 ./binary http://localhost:6060/debug/pprof/goroutine?debug=2 查看 goroutine 泄漏
• 若 trace 显示大量 goroutine 处于 runnable 状态但迟迟得不到 P，说明 P 不足或存在长耗时非阻塞 CPU 计算（应拆成小块并插入 runtime.Gosched()）

实际压测中，把 10k goroutine + unbuffered channel 的限流逻辑换成 semaphore.NewWeighted(10)（golang.org/x/sync/semaphore），QPS 提升 15–20%，GC pause 减少一半——因为后者完全避免 channel 调度路径，且基于 sync.Mutex fast path 实现。别为了“看起来更 Go”牺牲可测量的性能。