协程池必须绑定任务生命周期，否则易卡死或泄漏；应使用 semaphore.newweighted 替代裸 channel 信号量，避免因漏处理导致并发控制失效。
直接结论：协程池不是“加个库就完事”，它必须和任务生命周期绑定；不配 context 或不处理 panic，池子迟早卡死或泄漏。
用 semaphore.NewWeighted 替代裸 channel 信号量
很多人用 make(chan struct{}, 10) 控制并发，写起来快，但漏一次 就永久少一个槽位——尤其在 error 分支或 panic 时极易丢失。官方 <code>golang.org/x/sync/semaphore 是更稳的选择：
-
sem.Acquire(ctx, 1)必须检查返回 error；若 ctx 超时或取消，它不会阻塞，而是立刻返回错误，业务逻辑必须中止 -
defer sem.Release(1)要写在 goroutine 内部，且不能依赖闭包变量（比如for _, item := range items { go func() { ... }() }中的item会错乱） - 别在每个 HTTP handler 里 new 一个
semaphore；它该是全局单例，跟 server 生命周期一致 -
sem.TryAcquire(1)适合快速失败场景（如限流后直接返回 429），它不等、不看 context、不阻塞
Worker Pool 比信号量多管什么？
信号量只回答“现在能跑几个”，而 Worker Pool 回答“谁来跑、跑几次、挂了怎么办”。当你遇到这些情况，就得升维：
- 任务积压时想主动拒绝新请求（而不是让调用方无限等待），得靠带缓冲的任务队列 + 显式拒绝逻辑
- 需要统计当前运行数、排队数、平均耗时，得暴露
len(pool.Work)和cap(pool.Work)等可观测指标 - 某些任务长期 hang（比如第三方接口无响应），光靠信号量无法熔断，必须结合
context.WithTimeout在任务内部控制 - goroutine panic 后要自动 recover 并释放资源，否则 worker 协程退出，池子实际容量缩水
gorush 配置里 core.worker_num 和 core.queue_num 怎么设？
这两个值不是拍脑袋定的，得看真实负载特征：
-
core.worker_num默认为 0，表示自动设为 CPU 核心数；但如果你的任务是 I/O 密集型（比如发 HTTP 请求），可设为 CPU 数的 2–5 倍；如果是 CPU 密集型（比如图像压缩），建议 ≤ CPU 核心数 -
core.queue_num是任务缓冲区大小；设太小（如 100）会导致突发流量直接被拒；设太大（如 100w）可能 OOM；推荐从 8192 起步，上线后根据queue_length监控指标动态调整 - 不要把任务队列设成无缓冲 channel（
make(chan func())），那等于没缓冲，一塞满就阻塞提交方，容易引发级联超时
为什么 ants 比手写 Pool 更适合生产？
github.com/panjf2000/ants 不只是“预启 goroutine”，它把易错点都封装好了：
- 内置 panic 捕获：worker 崩溃后自动重启，池容量不缩水
- 支持
SubmitWithTimeout：用select+time.After包裹任务提交，避免调用方无限等待 - 提供
RunningWorkers、FreeWorkers、WaitingTasks等运行时指标，方便接入 Prometheus - 动态伸缩能力（需开启）：低负载时回收部分 worker，避免空转消耗调度器资源
- 但它不是万能的——如果任务本身有长连接或状态缓存，伸缩反而导致连接复用率下降，这时得关掉动态模式，固定 size
真正难的从来不是“怎么起 pool”，而是“怎么定义一个任务的完整生命周期”：从进队列、拿令牌、执行、超时判断、panic 恢复、到结果回调或重试——每个环节漏一环，池子就在你没注意的时候悄悄失血。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
