应按需复用、延迟启动、避免裸建goroutine；用sync.Pool缓存依赖对象减少GC；用worker pool限制并发数并复用goroutine，避免每任务启一个导致线性增长。
频繁创建 goroutine 会导致调度器压力上升、内存分配增多、GC 负担加重，尤其在高并发短生命周期任务中（如 HTTP 请求处理、消息解析），go f() 每秒调用上万次时，开销会明显拖累吞吐量。关键不是“少用 goroutine”，而是“按需复用、延迟启动、避免裸建”。
用 sync.Pool 缓存 goroutine 所依赖的上下文对象
goroutine 本身轻量，但常伴随结构体、缓冲区、连接等堆分配。直接在 go 语句里 new 会导致高频 GC。
- 不要在 goroutine 启动前 new 大对象：
go func() { data := make([]byte, 4096); process(data) }() - 改用
sync.Pool预分配并复用：var bufPool = sync.Pool{ New: func() interface{} { return make([]byte, 0, 4096) }, } // 使用时 buf := bufPool.Get().([]byte) buf = buf[:0] // ... use buf bufPool.Put(buf) -
sync.Pool不保证 Get 一定命中，不能依赖其“一定有值”；Put 前确保清空敏感字段，避免数据残留
用 worker pool 模式限制并发数 + 复用 goroutine
把“为每个任务启一个 goroutine”改为“固定 N 个长期运行的 goroutine 从队列取任务”，能彻底消除创建/销毁开销，并控制资源上限。
- 典型错误：每来一个请求就
go handle(req)→ goroutine 数随 QPS 线性增长 - 正确做法：启动固定数量的 worker，用
chan分发任务type Worker struct { jobs <-chan *Request done chan<- struct{} } func (w *Worker) Run() { for req := range w.jobs { handle(req) } w.done <- struct{}{} } // 启动 8 个 worker jobs := make(chan *Request, 100) done := make(chan struct{}, 8) for i := 0; i < 8; i++ { go (&Worker{jobs: jobs, done: done}).Run() } - 注意
jobschannel 容量要设合理缓冲，避免 sender 阻塞；worker 异常退出需有重启或告警机制
用 runtime.Gosched() 替代短时 goroutine 拆分
有些场景本意只是“让出 CPU 避免阻塞”，比如循环中做简单计算但想防止单次执行过长。此时起 goroutine 是过度设计。
立即学习“go语言免费学习笔记（深入）”；
- 错误示范：
go func() { for i := 0; i —— 只为 yield，却引入调度开销 - 更轻量的做法：在循环中插入
runtime.Gosched()，主动让出时间片for i := 0; i < 1e6; i++ { compute(i) if i%1000 == 0 { runtime.Gosched() // 每千次让出一次 } } -
runtime.Gosched()不创建新 goroutine，仅提示调度器可切换，适用于已知耗时可控、无需真正并发的场景
goroutine 的创建成本虽低（约 2KB 栈 + 调度元信息），但在微服务或网关类系统中，每秒数万次的创建销毁仍会成为瓶颈。真正难的是判断哪些该池化、哪些该合并、哪些其实根本不需要并发——这得看任务粒度、IO 类型和超时约束，不能只盯着 go 关键字删减。
