直接用go func()启动协程在高并发下会因goroutine数量失控导致调度器过载、GC压力剧增、内存飙升乃至OOM；ants协程池需显式配置expiry、nonblocking和panic handler，如ants.NewPool(50)控制最大并发，WithIdleTimeout防泄漏，WithMaxBlockingTasks限队列，WithNonblocking避免阻塞，且必须调用pool.Release()并配WithPanicHandler确保可观测性。
直接用 go 启动协程在高并发下会出什么问题
不是“能不能用”，而是“用多久就崩”。每启动一个 goroutine 至少占 2KB 栈空间，上万任务 → 20MB+ 内存；调度器要管理成千上万个 G，GC 扫描压力陡增；更隐蔽的是 os/exec.Command 类操作会 fork 新进程，系统级资源（PID、文件描述符）很快耗尽，fork: cannot allocate memory 就是典型报错。
用 ants 库初始化协程池的关键参数怎么设
别盲目套“CPU核数 × 2”这种经验公式。真实瓶颈往往不在 CPU，而在 I/O 或外部依赖：
-
ants.NewPool(50)：适用于 HTTP 客户端调用或 DB 查询，50 是多数服务的稳妥起点 -
ants.NewPool(10, ants.WithIdleTimeout(60*time.Second))：空闲超 60 秒自动回收 worker，防长连接泄漏 -
ants.NewPool(100, ants.WithMaxBlockingTasks(1000))：队列最多积压 1000 个任务，超量时Submit()返回ants.ErrPoolOverload，需降级处理 - 拒绝策略必须显式设：
ants.WithNonblocking()让Submit()立即失败，避免阻塞调用方
提交任务时为什么 pool.Submit() 总是返回 error
常见原因不是代码写错，而是池状态或配置不匹配：
- 池已
Release()关闭，再提交 →ants.ErrPoolClosed - 队列满且没配
WithMaxBlockingTasks→ 默认阻塞，但若用了WithNonblocking()就直接返回ants.ErrPoolOverload - 任务函数里 panic 未被捕获 →
ants默认 recover，但不会透出 panic 原因，需配合ants.WithPanicHandler打日志 - 忘记用
defer pool.Release()→ 进程退出前 worker 不退出，下次启动可能连不上 Redis 或 DB 连接池
自己手写协程池时最容易漏掉的 shutdown 逻辑
很多人实现 worker 循环用 for task := range ch，却忘了关闭通道的时机：
立即学习“go语言免费学习笔记（深入）”；
- 只 close(
taskChan) 不等WaitGroup→ worker 还在读 channel，导致 panic: “send on closed channel” - 用
sync.WaitGroup但没在每个 worker 的defer wg.Done()前加 recover → 某个 worker panic 后 wg 计数不减，Shutdown()死锁 - 没处理“正在执行的任务” → 应该先关通道，再等所有 worker 退出，期间新任务要拒绝，不能粗暴 kill goroutine
- HTTP server 中启 pool 但没注册
http.Server.RegisterOnShutdown→ SIGTERM 来了直接退出，积压任务丢失
WithPanicHandler 和 WithIdleTimeout，线上照样静默泄漏。 
