协程池是高并发任务落地的必经关卡；直接用go task()会导致内存不可控、下游资源打满、无超时重试等三大硬伤，需用ants池配合context实现可控调度。
协程池不是“选配”，而是高并发任务落地的必经关卡——不加限制的 go task() 在真实流量下大概率触发 OOM 或被系统 kill。
为什么不能直接用 go task() 启动大量协程
看似一行代码就能并发，但真实场景中它会快速暴露三个硬伤：
- 内存不可控：每个 goroutine 至少占 2KB 栈空间，10 万并发 ≈ 200MB 内存，加上 GC 压力，服务极易抖动甚至崩溃
- 下游资源打满：比如数据库连接池默认 100，若 500 个 goroutine 同时发 query，90% 会阻塞在
db.Query上，吞吐反而暴跌 - 无超时、无重试、无拒绝反馈：任务失败静默丢弃，调用方收不到
ants.ErrPoolOverload这类明确背压信号，只能被动等雪崩
用 ants 池做基础调度：四步跑通不踩坑
选 ants 是因为它的 API 极简、生产验证充分，且默认行为就规避了多数新手陷阱：
- 安装：
go get -u github.com/panjf2000/ants/v2 - 初始化（建议放
init或全局变量）：pool, _ := ants.NewPool(100)—— 这里100是最大并发数，不是 worker 数量 - 提交任务：
pool.Submit(func() { doWork() })，注意别漏 error 判断；若返回ants.ErrPoolOverload，应降级为同步执行或写入本地队列 - 关闭池子：
pool.Release()必须在服务退出前调用，否则 worker 协程常驻，内存泄漏
任务要带 context.Context，否则超时控制形同虚设
协程池本身不感知 context，所有超时逻辑必须由任务函数自己实现：
- 错误写法：
pool.Submit(func() { time.Sleep(10 * time.Second) })—— 完全无法中断 - 正确写法：
pool.Submit(func() { select { case - 如果任务含 IO（HTTP/DB），必须把
ctx透传到底层方法，例如http.DefaultClient.Do(req.WithContext(ctx)) - 不要在 worker 内部统一加 ctx——每个任务生命周期独立，超时策略也应独立
限流不是靠池大小兜底，得用 channel 信号量二次控制
ants.NewPool(100) 控制的是最大并发数，但若任务本身是“每秒涌进 5000 个”的突发流量，缓冲队列可能瞬间积压上万待执行任务，内存照样爆：
- 推荐组合方案：用带缓冲的
sem := make(chan struct{}, 5)作为信号量，在 Submit 前先sem ，执行完立刻 <code> - 这个
sem必须是全局或闭包捕获的，不能在每个 goroutine 里重新声明 - 比单纯依赖
sync.WaitGroup更有效：WaitGroup 只管等待，不阻止新任务提交；channel 信号量才是真正阻塞源头
真正难的不是让 100 个任务并发跑起来，而是当其中 5 个因网络卡住 30 秒、3 个 panic 导致 worker 退出、还有 20 个正在排队时，你的池子是否还能稳住吞吐、不丢任务、不泄漏 goroutine——这些边界，往往只在压测和线上故障时才浮现。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
