goroutine创建开销小但高频调用会引发调度、内存分配和GC压力；应优先复用，如用worker pool模式，数量建议2×NumCPU()，channel缓冲设为worker数的2–4倍。

goroutine 创建开销到底有多大？

goroutine 本身开销极小（初始栈仅 2KB，调度由 Go runtime 管理），但频繁创建/销毁仍会触发调度器工作、内存分配和 GC 压力。真实瓶颈往往不在单个 goroutine，而在 go f() 被高频调用时——比如每毫秒启动数百个，或在 hot path 中循环启 goroutine。

典型信号：pprof 显示 runtime.newproc 或 runtime.malg 占比突增；GC pause 时间变长；GOMAXPROCS 较高时系统线程数暴涨（ps -T -p $(pidof yourapp) 可验证）。

优先复用 goroutine：worker pool 模式

避免“来一个请求启一个 goroutine”，改用固定数量的长期运行 worker，从 channel 消费任务。这是最直接降低创建频次的方式。

• 适用于 I/O-bound 或短时 CPU-bound 任务（如 HTTP handler 中的 DB 查询、JSON 解析）
• worker 数量不建议硬编码，应基于 runtime.NumCPU() 或实际压测结果调整（通常 2 * runtime.NumCPU() 是较稳起点）
• channel 缓冲区大小需权衡：太小导致 sender 阻塞，太大浪费内存；常见设为 worker 数量的 2–4 倍

type WorkerPool struct {
    jobs chan func()
    wg   sync.WaitGroup
}
func NewWorkerPool(n int) WorkerPool {
p := &WorkerPool{jobs: make(chan func(), n4)}
for i := 0; i < n; i++ {
go p.worker()
}
return p
}
func (p *WorkerPool) Submit(job func()) {
p.jobs <- job
}
func (p *WorkerPool) worker() {
for job := range p.jobs {
job()
}
}

避免在循环中无节制启 goroutine

常见错误是把 for range 和 go 直接组合，尤其当迭代量大或不可控时：

// ❌ 危险：若 items 有 10 万项，就启 10 万个 goroutine
for _, item := range items {
    go process(item)
}
// ✅ 改用批量 + worker pool，或限制并发数
sem := make(chan struct{}, 10) // 最多 10 并发
for _, item := range items {
sem <- struct{}{}
go func(i Item) {
defer func() { <-sem }()
process(i)
}(item)
}

注意闭包陷阱：item 必须传参进 goroutine，否则所有 goroutine 共享循环变量最后一值。

什么情况下真没必要省 goroutine？

Go 的设计哲学是“goroutine 很便宜，大胆用”。以下场景无需过度优化：

• HTTP server 中每个请求启一个 goroutine（net/http 默认行为）——这是合理且推荐的
• 生命周期与请求/事务一致的短期任务（如一次 RPC 调用包装）
• goroutine 总数稳定在数千以内，且无明显调度延迟（可通过 go tool trace 查看 Goroutines > Scheduler > Goroutines count）

真正要警惕的是“动态生成量级不可控 + 生命周期短 + 高频触发”的组合，比如日志采样、指标打点、连接空闲检测等后台轻量任务——这些最容易堆积 goroutine 导致资源泄漏。