直接用go func()启动协程会崩，根本原因是goroutine数量失控导致调度器过载和gc压力剧增，而非单个协程重量问题；ants需显式配置expiry、nonblocking和panic handler才可安全用于生产环境。
为什么直接用 go func() 启动协程会崩
不是协程“重”，是数量失控后调度器和内存一起扛不住。每个 goroutine 初始栈 ≥2KB，1 万个就是 20MB+；更致命的是 runtime 调度器在 P 队列频繁偷任务、全局队列争抢时退化明显，GC 扫描所有 goroutine 栈也变慢——线上服务常因此延迟飙升或 OOM。
- 典型症状：
runtime: goroutine stack exceeds 1GB limit、pprof显示大量 goroutine 处于chan receive或select等待态、内存 RSS 持续上涨不回落 - 高危场景：HTTP handler 中每请求
go doDBQuery()、批量发 HTTP 请求未限流、日志异步写入没缓冲 - 关键误判：以为“Go 协程轻量 = 可无限创建”，其实瓶颈不在单个开销，而在总量带来的调度与 GC 压力
ants 库怎么配才不踩坑
ants 是目前最稳的开箱即用选择，但默认配置容易误导人——它不自动回收空闲 worker，也不默认拒绝超载任务，全靠你手动设对参数。
-
ants.NewPool(50)只控制最大并发数，任务超 50 个会排队，不扩容；若队列满且没设拒绝策略，pool.Submit()会阻塞（不是你想要的“失败快”） - 必须显式调用
pool.Release()，否则 worker goroutine 永不退出，进程无法优雅关闭 - panic 默认被 recover，但错误不打印——要加
ants.WithPanicHandler(func(r interface{}) { log.Printf("panic: %v", r) }) - 生产环境建议：容量设为后端依赖（如 DB 连接池、Redis 客户端并发上限）的 80%，队列长度设为
capacity * 5
手写协程池时 chan 的三个致命陷阱
很多人用 make(chan struct{}, N) + select 模拟“池”，但这只是信号量，根本没复用 goroutine——每次任务仍新建 goroutine，完全违背池的本意。
- 陷阱一：用
chan struct{}当信号量，worker 启动后立即退出，任务来了再go worker()—— 这等于没池 - 陷阱二：任务 channel 无缓冲且没配超时，
pool.Submit()在队列满时永久阻塞，拖垮上游逻辑 - 陷阱三：没处理 panic，一个任务 panic 会导致整个 worker goroutine 死掉，池可用数悄悄下降，直到全部挂掉
- 安全写法：用带缓冲的
chan func()（大小 ≥ capacity），每个 worker 循环读取；任务函数内包一层defer recover()；加quit chan struct{}支持关闭
池大小和任务类型必须匹配
设错 capacity 比不用池还危险：太小压不住流量，太大又浪费资源。关键看任务是 CPU 密集型还是 IO 密集型，以及依赖服务的吞吐瓶颈。
- IO 密集型（HTTP 请求、Redis 查询）：可设较大值（如 100–500），因大部分时间在等网络响应，goroutine 处于休眠态，调度压力小
- CPU 密集型（JSON 解析、图像缩放）：必须严格限制（如 4–16），避免抢占过多 P，导致其他 goroutine 饿死；建议配合
runtime.Gosched()主动让出 - 混合型任务：按最慢依赖定上限——比如 DB 连接池只允许 20 个并发，那协程池
capacity就不能超过 20
真正难的不是写出来，是把 capacity 和 queueSize 调到既扛住峰值又不浪费资源的位置，这得靠真实压测数据，不是凭经验拍脑袋。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
