Go中无内置goroutine池，本质是固定数量goroutine+带缓冲channel实现任务复用；必须用带缓冲channel避免Submit同步阻塞；缓冲大小应≈峰值积压量×1.5，过小退化为同步，过大导致内存滞留和吞吐问题；生产环境建议select+default过载丢弃。
Go 里没有“goroutine 池”这个内置概念，所谓“池”，本质是用固定数量的
+ 带缓冲的
实现任务复用——不是复用协程本身（协程不能复用），而是避免为每个任务都新建一个。
为什么必须用带缓冲的
channel？
无缓冲
是同步点：
会卡住，直到有空闲 worker 取走任务。高并发下极易阻塞调用方，尤其在 HTTP handler 中直接
就可能拖垮整个请求链路。
缓冲区大小 ≠ worker 数量，而应 ≈ 单次峰值积压量 × 1.5（例如每秒最多涌进 200 个任务，平均处理耗时 50ms，缓冲设 300 更稳）
过小（如
）等于没缓冲，退化成同步调用
过大（如
）会让任务滞留内存，GC 回收延迟，且掩盖了消费者吞吐不足的问题
生产环境建议配合
+
做过载丢弃：
如何安全关闭池并等待所有任务完成？
直接
不等于所有任务已执行完——worker goroutine 可能还在跑，
退出后就结束了，但最后几个任务可能刚被取出、尚未执行完毕。
不能只靠
，必须用
或
跟踪实际执行完成
worker 内部要
，且
必须在
前调用
关闭流程顺序不能错：
先停生产者（关闭 tasks chan），再，最后才真正释放资源
别在
里直接
后就返回——这会让调用方误以为“已清空”，实际任务还在飞
要不要给任务加
？
不加，就是“甩出去不管”；加了，才能支持超时、取消、透传 deadline——这对 I/O 密集型任务（HTTP 请求、DB 查询）几乎是刚需。
立即学习
“
go语言免费学习笔记（深入）
”；
原始
无法响应取消；应升级为
worker 中必须用
监听
，并在收到时立即退出，避免任务“幽灵执行”
注意：不要把
放在 Submit 侧统一包一层——那样所有任务共享同一个 deadline，不合理；应在每个任务创建时按需设置
若任务本身不含 I/O，纯计算，context 开销略增（少量字段拷贝），但换来的是可观察、可中断的能力，值得
最常被忽略的一点：worker goroutine 里的 panic 不会自动传播，也不触发
，会导致该 goroutine 静默死亡，池子悄悄少掉一个 worker。上线前务必在 worker 主循环里加
。
goroutinechantaskschanSubmitpool.Submit(...)make(chan Task, 1)make(chan Task, 10000)selectdefaultselect {
case p.tasks <- task:
default:
// 记录告警或返回错误
}close(p.tasks)rangeclose(p.tasks)sync.WaitGrouperrgroup.Groupdefer wg.Done()wg.Add(1)go worker()wg.Wait()Close()close(p.tasks)context.Contexttype Task func()type Task func(context.Context) errorselectctx.Done()context.WithTimeoutrecoverdefer func() { if r := recover(); r != nil { log.Printf("worker panic: %v", r) } }()