直接用 go f() 易致服务崩溃，因每 goroutine 至少占 2KB 栈内存，高并发下易 OOM 或 GC 卡顿，且无并发控制会打穿下游限流；应使用 unbuffered/small-buffered channel 配固定 worker 池实现背压与资源复用。
为什么直接用 go f() 容易把服务搞崩
协程（goroutine）开销小，但不等于没有成本。每启动一个 go f()，至少占用 2KB 栈空间，频繁创建成千上万个，会迅速耗尽内存或触发调度器争抢，尤其在高并发 HTTP 请求中，容易出现 runtime: out of memory 或 GC 频繁卡顿。
更隐蔽的问题是：没控制并发数，下游依赖（比如数据库连接池、第三方 API 限流）直接被打穿，错误不是出现在 Go 代码里，而是表现为 timeout、connection refused 或 429 响应，排查时容易误判为网络或外部服务问题。
- 真实场景下，1000 个请求 → 1000 个 goroutine → 可能对应 1000 次 DB 查询，而你的
max_open_connections只设了 50 -
go f()启动后完全异步，无法统一等待、超时或取消，任务失败也难追踪 - 协程泄漏风险高：忘记
defer wg.Done()或 panic 未 recover，会导致WaitGroup永远等不到完成
用 sync.WaitGroup + chan 实现最简 Worker Pool
核心就两件事：固定数量的长期运行 worker，从任务队列里取活干；主流程只往队列塞任务，不直接起 goroutine。这样并发数被硬性卡死，且资源复用。
关键不是“池子多高级”，而是队列和 worker 的生命周期是否匹配。别用 buffered channel 当任务队列来省事——缓冲区满就会阻塞发送方，反而让上游逻辑卡住，失去背压控制能力。
立即学习“go语言免费学习笔记（深入）”；
- 任务 channel 必须是
unbuffered或小缓冲（如make(chan Task, 10)），避免积压掩盖瓶颈 - worker 要用
for range读 channel，channel 关闭后自动退出，别写for { select { case t := 然后忘了退出条件 -
WaitGroup的Add必须在启动 worker 前调用，且数值固定；Done放在 worker 函数末尾，确保无论正常返回还是 panic 都执行（可用defer）
workers := 5
tasks := make(chan Task, 10)
var wg sync.WaitGroup
<p>for i := 0; i < workers; i++ {
wg.Add(1)
go func() {
defer wg.Done()
for t := range tasks {
t.Process()
}
}()
}</p><p>// 发送任务（非阻塞，因有缓冲）
for _, t := range allTasks {
tasks <- t
}
close(tasks) // 关键：关闭 channel，通知所有 worker 退出
wg.Wait()
context.Context 怎么安全注入到 Worker Pool
单纯传 context.Context 到每个 task 里不够——worker 本身可能卡在某个 I/O 上（比如 http.Do、db.Query），需要能随上下文取消。但不能把 ctx 直接传给 range 循环，channel 读操作不响应 cancel。
正确做法是：worker 内部用 select 包裹任务获取，并监听 ctx.Done()；同时每个 task 执行时，也要把 ctx 透传给它调用的可取消函数（如 http.NewRequestWithContext）。
- 别在 worker 启动前就
ctx, cancel := context.WithTimeout(...)然后只传ctx进去——cancel 函数没人调，超时不会触发 - worker 中的
select必须包含default分支或合理超时，否则可能永远阻塞在ctx.Done()上，错过新任务 - 如果 task 本身含长时计算（非 I/O），需定期检查
ctx.Err() != nil，手动退出，Go 不会自动中断 CPU 密集型操作
要不要用第三方库比如 panjf2000/ants
如果你的场景只是“限制并发数 + 等待完成”，原生 sync.WaitGroup + chan 足够，加库反而引入额外复杂度和隐藏行为（比如 ants 默认重用 goroutine 栈，某些情况下会干扰 pprof 分析）。
真正值得切过去的情况很具体：需要动态扩缩 worker 数量、任务优先级队列、或内置熔断/重试/统计上报。但这些需求一出现，往往意味着业务逻辑已超出“简单并发控制”范畴，该考虑消息队列或专用任务系统了。
-
ants.Submit()返回error表示队列满，但默认配置下这个“满”是基于内存估算，不是精确的 pending 任务数，监控困难 - 它的
PanicHandler是全局设置，一旦出错容易掩盖真实 panic 位置，调试时比原生更绕 - 升级 Go 版本时，某些老版本 ants 对
GOOS=js或 tinygo 不兼容，而原生方案无此风险
复杂点从来不在“怎么起 pool”，而在“任务失败了谁负责重试”“中间状态怎么持久化”“worker 挂了任务会不会丢”。这些，再好的 pool 库也不会替你决定。
