协程池核心作用是限并发与可控排队，而非单纯复用；用channel实现时若忽略关闭时机与同步等待，易致panic或任务丢失。
直接用 go func() 启动大量协程，在真实业务中大概率会触发 OOM 或被系统 kill——这不是理论风险，而是线上高频事故。协程池的核心作用不是“复用”，而是“限并发 + 可控排队”，所有实现都绕不开这个前提。
为什么用 channel 实现的简单池容易死锁或饥饿
很多人照搬示例写 for range tasks + close(tasks) 关闭，但忽略两个关键点：任务提交方可能还在往已关闭的 tasks channel 发数据，导致 panic：send on closed channel；worker 在 range 中退出后，若没同步等待，Submit 返回即认为成功，实际任务可能丢弃。
- 必须用
select { case p.tasks 实现非阻塞提交，否则调用方可能卡死 - 关闭前需先停写（如用
sync.Once控制），再close(p.tasks)，最后用sync.WaitGroup等待所有 worker 退出 - 若任务执行中 panic，不显式 recover 会导致 worker 协程退出，池容量永久减少
ants 库 Submit 失败时该怎么做
ants 的 Submit 在池满且拒绝策略为 Deny（默认）时返回 ants.ErrPoolOverload，这不是异常，而是明确的背压信号。
- 不要忽略这个 error，更不要用
log.Fatal直接终止程序 - 常见合理响应：降级为同步执行（
task()）、写入本地队列稍后重试、返回 HTTP 429 给上游 - 若用
ants.WithNonblocking(true)，Submit会立即返回 error，但不会排队；想排队就得关掉 nonblocking，并配好queueSize - 注意：
ants.NewPool(n)的n是最大并发数，不是 worker 数量——它内部按需创建/回收，和手写固定数量 worker 的语义不同
如何给任务加 context 超时控制
协程池本身不感知 context，超时必须由任务函数自己处理。把 context.Context 塞进 task 闭包是最直接的方式。
- 错误示范：
pool.Submit(func() { time.Sleep(10 * time.Second) })—— 完全无法中断 - 正确做法：
pool.Submit(func() { select { case - 如果任务涉及 IO（如 HTTP 请求、DB 查询），务必把
ctx传给底层 client 方法，例如http.DefaultClient.Do(req.WithContext(ctx)) - 不要在 worker 内部统一加
ctx——每个任务生命周期独立，超时策略也应独立
真正难的不是启动几个 goroutine，而是当 5000 个任务涌入、其中 3% 会卡住 30 秒、还有 1% 会 panic 时，你的池子是否还能稳住吞吐、不泄漏、不雪崩。这些边界情况，往往在压测时才暴露，而修复它们依赖的不是技巧，是设计时对 channel 关闭时机、panic 传播路径、context 生命周期的清晰判断。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
