直接go handler()会崩不是协程不够轻，而是调度器扛不住无序堆积的goroutine；每个goroutine需排队、抢占、栈扩容和gc扫描，qps上千时numgoroutine易破5000，属失控信号。
为什么直接 go handler() 在高并发下会积压任务
不是协程不够轻，而是调度器扛不住无序堆积。每个 go handler() 启动的 goroutine 都要排队进全局运行队列、被 P 抢占、触发栈扩容、参与 GC 扫描。QPS 上千时，runtime.NumGoroutine() 很容易突破 5000——这不是高并发，是失控信号。
典型现象包括：HTTP 请求延迟飙升、DB 连接池耗尽、dial tcp: lookup xxx: no such host 错误频发、大量 goroutine 卡在 select 或 net.Conn.Read 上。
- 根本原因不是 CPU 不够，而是任务没有节制地涌入，挤占了调度器和系统资源
- 没有超时控制的 goroutine 一旦卡住（如慢 DB 查询、第三方 HTTP 调用），就会永久悬停，拖垮整个池
- 未设缓冲的
chan func()会导致提交任务时阻塞，让上游 HTTP handler 直接 hang 住
协程池必须带 context.WithTimeout 和带缓冲的 chan
协程池不是“把 goroutine 数量固定下来”就完事了；它得能防住单点故障，也得能控住资源水位。
-
tasks chan func()必须带缓冲，容量建议 100–1000；盲目设大（如 10000）会导致内存占用陡增、任务入队延迟不可控 - 每个 worker 内部执行任务前，必须包裹
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)，并在任务结束时defer cancel() - 提交任务必须用
select { case pool.tasks ，避免阻塞 handler - worker 启动数别硬绑
runtime.NumCPU()：IO 密集型服务可设为2 * runtime.NumCPU()起步；纯计算型务必 ≤runtime.NumCPU()
http.DefaultClient 的连接池参数不调优，协程池白搭
即使协程池控住了 goroutine 数量，如果每个请求都反复建连、复用失败，照样会触发 DNS 解析失败、连接拒绝、TLS 握手卡死等问题——此时你看到的“积压”，其实是底层连接层在掉链子。
-
MaxIdleConns：全局最大空闲连接数，建议设为100；低于此值才新建连接 -
MaxIdleConnsPerHost：必须显式设为 ≥20（HTTP/1.1 默认仅2），否则同一域名的请求全堵在连接等待上 -
IdleConnTimeout：设为90s，比后端服务的 idle timeout 略短，避免被对方断连后还傻等 - 别漏掉
KeepAlive（保持长连接活跃）和TLSHandshakeTimeout（防握手悬挂导致 goroutine 悬停）
框架集成时最容易忽略的三点
用 Gin/Echo/go-zero 等框架时，协程池常被当成“独立模块”嵌进去，但实际运行中几个关键点极易被绕过：
- 中间件里没做 panic 捕获，一个未处理的 panic 会让 worker goroutine 退出，池子悄悄缩水
- 数据库操作没走
context透传（比如db.QueryContext(ctx, ...)），timeout 控制形同虚设 - 结果通道（
results chan Result）没设缓冲或没及时消费，导致 worker 在results 处阻塞，整个池逐步僵死
真正稳的协程池，不是靠数量压住流量，而是靠 timeout、buffer、conn pool、panic recover 四层兜底。少一层，积压就可能从某次网络抖动开始。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
