goroutine创建开销小但高频调用会引发调度、内存分配和GC压力；应优先复用，如用worker pool模式，数量建议2×NumCPU()，channel缓冲设为worker数的2–4倍。
goroutine 创建开销到底有多大？
goroutine 本身开销极小（初始栈仅 2KB，调度由 Go runtime 管理），但频繁创建/销毁仍会触发调度器工作、内存分配和 GC 压力。真实瓶颈往往不在单个 goroutine，而在
被高频调用时——比如每毫秒启动数百个，或在 hot path 中循环启 goroutine。
典型信号：pprof 显示
或
占比突增；GC pause 时间变长；
较高时系统线程数暴涨（
可验证）。
优先复用 goroutine：worker pool 模式
避免“来一个请求启一个 goroutine”，改用固定数量的长期运行 worker，从 channel 消费任务。这是最直接降低创建频次的方式。
适用于 I/O-bound 或短时 CPU-bound 任务（如 HTTP handler 中的 DB 查询、JSON 解析）
worker 数量不建议硬
编码
，应基于
或实际压测结果调整（通常
是较稳起点）
channel 缓冲区大小需权衡：太小导致 sender 阻塞，太大浪费内存；常见设为 worker 数量的 2–4 倍
避免在循环中无节制启 goroutine
常见错误是把
和
直接组合，尤其当迭代量大或不可控时：
立即学习
“
go语言免费学习笔记（深入）
”；
php版微信js-sdk支付接口类
php版微信js-sdk支付接口类
下载
注意闭包陷阱：
必须传参进 goroutine，否则所有 goroutine 共享循环变量最后一值。
什么情况下真没必要省 goroutine？
Go 的设计哲学是“goroutine 很便宜，大胆用”。以下场景无需过度优化：
HTTP server 中每个请求启一个 goroutine（
默认行为）——这是合理且推荐的
生命周期与请求/事务一致的短期任务（如一次 RPC 调用包装）
goroutine 总数稳定在数千以内，且无明显调度延迟（可通过
查看 Goroutines > Scheduler > Goroutines count）
真正要警惕的是“动态生成量级不可控 + 生命周期短 + 高频触发”的组合，比如日志采样、指标打点、连接空闲检测等后台轻量任务——这些最容易堆积 goroutine 导致资源泄漏。
go f()runtime.newprocruntime.malgGOMAXPROCSps -T -p $(pidof yourapp)runtime.NumCPU()2 * runtime.NumCPU()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()
}
}
for rangego// ❌ 危险：若 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)
}
itemnet/httpgo tool trace