直接用go func()处理万级并发会崩，因调度器、内存、文件描述符等资源无法兜住，导致OOM、too many open files、HTTP超时等；应使用协程池（如ants）或channel限流，避免无节制创建goroutine。
为什么直接用 go func() 处理万级并发会崩
不是协程太轻，是调度和资源没兜住。默认 runtime.GOMAXPROCS 通常等于 CPU 核数，但上万个 go func() 会瞬间创建等量 goroutine，它们争抢调度器、堆内存、文件描述符、TCP 连接池，甚至触发 GC 频繁 STW。
常见错误现象：panic: runtime: out of memory、too many open files、HTTP 超时陡增、P99 延迟跳变到秒级。
- goroutine 启动开销虽小（2KB 栈），但上万并发下栈总占用、GC 扫描压力、调度队列长度都会指数级上升
- 没有节制的
go func()相当于把背压逻辑甩给操作系统，而 Go 的 runtime 不会自动限流 - 多数业务场景真正需要的是“同时活跃处理 N 个任务”，不是“同时存在 N 个 goroutine”
ants 池 vs 手写 channel 控制：选哪个更稳
ants 是目前最成熟的 Go 协程池库（by panjf2000），它解决了动态伸缩、任务超时、panic 捕获、统计埋点等手写易漏的点；纯 channel + select 控制虽轻量，但容易在边界场景失控。
使用场景差异：
立即学习“go语言免费学习笔记（深入）”；
- 用
ants：需稳定支撑 5k+ QPS 的 HTTP 服务、批量消息消费、定时任务分发 - 手写 channel：极简 CLI 工具、单次跑批且并发可控（
性能影响：实测 10k 并发下，ants 池比裸 go func() 内存低 40%，P99 延迟稳定在 3ms 内；而手写 channel 若未加超时/熔断，延迟毛刺明显。
示例关键参数：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
pool, _ := ants.NewPool(100, ants.WithNonblocking(true), ants.WithMaxBlockingTasks(1000))
注意 WithNonblocking(true) 表示任务提交失败直接丢弃（适合日志类），WithMaxBlockingTasks 控制等待队列上限，避免 OOM。
自定义协程池必须设这 3 个参数
不设等于裸奔。哪怕只用标准库 sync.Pool + chan 组合，也得显式约束这三项：
-
workerCount：初始 worker 数，建议设为runtime.NumCPU() * 2起步，再按压测调优 -
taskQueueSize：任务缓冲通道容量，不能为 0（否则阻塞提交者），也不宜过大（如 >5000 易拖垮内存） -
taskTimeout：单个任务最大执行时间，必须用context.WithTimeout包裹业务逻辑，防止某个 goroutine 卡死拖垮整池
容易踩的坑：defer recover() 放在 worker 循环外就无效；close(taskChan) 后没等所有 worker 退出就释放资源，导致 panic；用 sync.WaitGroup 但忘记 Add 导致提前返回。
HTTP 服务里怎么把请求塞进协程池不丢不乱
核心原则：HTTP handler 本身不能长期阻塞，池只负责“取任务 → 执行 → 回写响应”，中间任何环节都不能让请求上下文丢失。
正确姿势：
- 在 handler 里立即从
context提取必要数据（如userID、reqID），封装成轻量结构体传入池，别传*http.Request或http.ResponseWriter - 池内执行完后，用原始
context的 value 或 closure 捕获响应写入逻辑，例如：func() { w.WriteHeader(200); w.Write([]byte("ok")) } - 务必设置
http.Server.ReadTimeout和WriteTimeout，否则慢客户端会让 worker 卡在 Write 阶段，池迅速耗尽
反模式示例：pool.Submit(func() { json.NewEncoder(w).Encode(data) }) —— 错，w 不是 goroutine 安全的，且可能已被 client 断开。
复杂点在于：每个请求的 context cancel、trace span、log fields 都要透传进池，漏掉任意一个，排查链路就断了。
