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
}
<p>func NewWorkerPool(n int) <em>WorkerPool {
p := &WorkerPool{jobs: make(chan func(), n</em>4)}
for i := 0; i < n; i++ {
go p.worker()
}
return p
}</p><p>func (p *WorkerPool) Submit(job func()) {
p.jobs <- job
}</p><p>func (p *WorkerPool) worker() {
for job := range p.jobs {
job()
}
}避免在循环中无节制启 goroutine
常见错误是把 for range 和 go 直接组合，尤其当迭代量大或不可控时：
立即学习“go语言免费学习笔记（深入）”；
// ❌ 危险：若 items 有 10 万项，就启 10 万个 goroutine
for _, item := range items {
go process(item)
}
<p>// ✅ 改用批量 + 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 导致资源泄漏。
