应使用ants或go-workerpool等成熟协程池库，池大小建议从runtime.NumCPU()*2起步并压测调优；避免每请求起goroutine，因其易引发高频GC、调度开销增大及I/O等待误导监控。
直接用 ants 或 go-workerpool 这类成熟协程池库，比手写更稳；池大小设为 runtime.NumCPU() * 2 起步，再结合压测调优，别硬套“核数×4”这种模糊经验。
为什么不能每请求起一个 goroutine？
看似轻量，但真实服务中容易暴露三个问题：
- 大量短生命周期 goroutine 触发高频 GC，
runtime.ReadMemStats().NumGC会明显跳升 - 调度器需维护更多 G 结构体，
runtime.NumGoroutine()持续高于 5000 时，GOMAXPROCS切换开销开始反噬吞吐 - 若任务含 DB 查询、HTTP 调用等 I/O，goroutine 会挂起等待，但 runtime 不知道它“实际空闲”，仍计入活跃数，误导监控
ants.NewPool() 的关键参数怎么选？
ants 是目前最常用的协程池库，它的初始化参数直接影响稳定性：
-
ants.NewPool(100)：只设容量，适合纯 CPU 密集型任务（如 JSON 解析、加解密） -
ants.NewPool(100, ants.WithNonblocking(true))：非阻塞模式，任务提交失败时直接丢弃或 fallback，避免 handler 卡在pool.Submit() -
ants.NewPool(100, ants.WithExpiryDuration(60*time.Second))：空闲 worker 60 秒后自动回收，防长连接场景下 goroutine 泄漏 - 慎用
ants.WithPreAlloc(true)：预分配会立即启动全部 worker，若任务不均，反而浪费内存
HTTP Handler 里怎么安全提交任务？
主请求流程不能被协程池阻塞，尤其要防 context 取消后任务还在跑：
立即学习“go语言免费学习笔记（深入）”；
- 必须把
context.Context传进异步任务，用ctx.Done()做退出判断，别依赖外部变量 - 不要在 pool 里直接
http.ResponseWriter.Write()—— response 已关闭，会 panic：write tcp ...: use of closed network connection - 日志、埋点、消息投递这类非关键路径操作，才适合丢进池；DB 写入、核心校验等必须同步执行
- 示例写法：
func handleOrder(w http.ResponseWriter, r *http.Request) { ctx := r.Context() // 同步处理订单核心逻辑 if err := processOrder(ctx, r); err != nil { http.Error(w, err.Error(), http.StatusBadRequest) return } <pre class="brush:php;toolbar:false;">// 异步上报埋点 pool.Submit(func() { // 注意：此处 ctx 已从 handler 传入，可感知超时/取消 _ = reportAnalytics(ctx, "order_created") })}
协程池和 HTTP Server 配置要联动
光调协程池没用，HTTP 层不配合，照样卡死：
-
http.Server必须显式设置ReadTimeout和WriteTimeout，否则慢连接会占满 worker，导致新任务排队饿死 -
SetKeepAlivesEnabled(true)要保持开启（默认已开），避免每个请求重建 TCP 连接，放大协程池压力 - OS 层的
net.core.somaxconn和进程级文件描述符限制（ulimit -n）必须 ≥ 协程池最大并发数 × 2，否则 accept 队列溢出，连接被内核丢弃 - 观察
http.Server.Stats()中的Idle和WaitCount：如果WaitCount持续增长，说明协程池或连接池都成了瓶颈，得一起调
协程池不是银弹——它只管“谁来干”，不管“干得对不对”。真正卡住性能的，往往是任务内部没做 context 控制、没设超时、没处理 cancel 信号。这些细节不补上，池子再大也白搭。
