协程池大小不应盲目设为 runtime.NumCPU() * 2，而应按任务类型区分：IO 密集型看下游资源容量，混合型取瓶颈环节最小值，纯计算型才参考 CPU 核数并预留余量。
协程池大小设成 runtime.NumCPU() * 2 是错觉
这个值常被当作“默认推荐”，但它只适用于 CPU 密集型任务且无外部阻塞调用的场景。真实服务里，大部分 goroutine 要等 HTTP、DB、RPC 或磁盘 IO —— 此时 CPU 核心数和并发能力几乎无关。
- IO 密集型任务（如 HTTP 客户端请求、MySQL 查询）：池大小应基于下游资源容量，比如数据库
max_open_connections设为 50，那池上限就不该超过 50，否则连接池打满，后续请求直接context deadline exceeded - 混合型任务（如先查 DB 再发 HTTP）：按瓶颈环节定，通常取 DB 连接数与第三方 API QPS 限流值的较小者
- 纯计算任务（如加解密、图像缩放）：才考虑
runtime.NumCPU()，但也要预留 20% 余量防调度抖动
缓冲队列长度不是越大越好，100 是多数场景的安全起点
缓冲通道 jobs chan Task 的容量决定你愿意让多少任务在内存里排队。设太大等于把背压转移到内存，设太小则上游提交频繁阻塞，吞吐掉得比延迟还快。
- 缓冲为 0（无缓冲 channel）：要求 worker 永远在线且响应及时，现实中几乎不可行；一卡就卡住整个提交流程
- 缓冲为 100：适配平均耗时 ≤200ms、峰值 QPS ≤500 的常见 Web 服务，能扛住约 2 秒突发流量
- 缓冲超 1000：除非你明确监控到 GC 压力低、内存充足、且任务失败可容忍积压（如日志异步写入），否则慎用
- 别用
len(jobs)当唯一指标——它不反映正在执行的任务数，只反映排队数；真正负载要看 worker 空闲率或任务平均等待时长
ants.Pool 的 Submit 返回 error 不是异常，是背压信号
很多人看到 ants.ErrPoolOverload 就 panic 或 log.Fatal，其实这是设计好的流控出口。你不处理它，等于主动放弃对下游的保护。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
pool.Submit(task)返回非 nil error 时，常见原因只有两个：ants.ErrPoolOverload（队列满）或ants.ErrTimeout（等待超时） - 降级策略必须前置：比如 fallback 到同步执行、写入本地队列重试、或返回 429 给客户端，而不是简单丢弃
- 拒绝策略别硬编码：
ants.WithNonblocking()可让Submit立即返回 error，避免阻塞；ants.WithMinIdleWorkers(5)能保底维持一定空闲 worker，减少冷启动延迟 - 注意：
ants.NewPool(50)中的 50 是最大并发数，不是初始数；空闲 worker 默认不会自动销毁，需配合ants.WithIdleTimeout(30 * time.Second)才会回收
recover 必须包在 worker 循环外，且要 log
worker 函数里漏掉 defer func() { recover() }()，或把它放在 for range jobs 循环内部，会导致单个 panic 让整个 goroutine 退出，池子悄悄缩水，任务越积越多却查不出原因。
立即学习“go语言免费学习笔记（深入）”；
- 正确位置：在 goroutine 启动函数最外层加
defer recover()，确保无论循环内还是循环外 panic 都被捕获 - recover 后必须
log.Printf或发告警——静默 recover 等于掩盖故障，你只会发现“某些任务没结果”，但看不到 panic 日志 - 别指望 recover 挡住所有问题：参数校验、context 超时、DB 连接空指针，这些本该在任务执行前拦截，而不是靠 recover 补救
- ants 默认做了 recover，但它的 panic handler 是空函数；必须显式传
ants.WithPanicHandler(func(r interface{}) { log.Printf("panic: %v", r) })
实际配比没有银弹。最可靠的起点是：先用 ants.NewPool(20) + make(chan Task, 100) 上线，再根据 pool.Stats().RunningWorkers 和 len(jobs) 的 95 分位值动态调优。真正容易被忽略的，不是数字本身，而是你是否把池子当黑盒——它暴露的每个指标，都是服务真实水位的镜像。
