goroutine并非越多越好，盲目增加会导致调度负担加重、内存暴涨和GC压力翻倍；判断是否失控关键看是否及时退出和持续增长，核心指标是runtime.NumGoroutine()走势及pprof分析。
goroutine不是越多越好，盲目增加数量反而会拖慢程序——调度器负担加重、内存暴涨、GC压力翻倍是常见后果。
怎么判断goroutine数量是否失控
关键不是看“起了多少”，而是看“有没有及时退出”和“是否持续增长”。最直接的指标是runtime.NumGoroutine()的走势：
- HTTP服务启动后稳定在 100–500 是正常范围；若每秒请求 1k 却涨到 5k+，大概率有泄漏
- 长连接服务（如 WebSocket）可接受稍高值，但需配合
pprof的goroutineprofile 确认活跃 goroutine 是否集中在业务逻辑而非阻塞调用 - 使用
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2查看完整堆栈，重点关注卡在select、chan receive、net.(*pollDesc).waitRead的 goroutine
http.HandlerFunc里起goroutine的典型陷阱
net/http 默认每个请求已运行在一个 goroutine 中，再套一层 go func() { ... }() 只会徒增开销，尤其容易引发三类问题：
- 闭包捕获大对象：比如直接引用
*http.Request或整个结构体，导致该 goroutine 栈无法收缩，内存常驻 - 错误的取消传播：新 goroutine 没传入
req.Context()，上游超时或断连时无法感知，任务继续执行 - 资源失控：每请求起 5 个 goroutine，QPS=2000 就意味着 1w 并发 goroutine，远超调度器舒适区
真正需要异步的场景（如日志上报、埋点），应走 worker pool + errgroup.Group，而不是在 handler 里随手 go。
立即学习“go语言免费学习笔记（深入）”；
worker pool 的最小可行实现要点
一个能落地的 pool 不需要复杂抽象，核心是控制并发数、复用 goroutine、支持优雅关闭：
- 任务 channel 必须带缓冲：
make(chan Task, 1024)，否则提交任务会阻塞主流程 - worker 数量别硬写成
runtime.NumCPU()——容器中它返回宿主机核数；应读取cgroups或显式配置，比如runtime.GOMAXPROCS(2) - 每个 worker 必须用
defer wg.Done()+recover()包裹，防止单个 panic 导致整个 pool 停摆 - 关闭时先关 task channel，再
wg.Wait()；不要用close(quit)后立刻 return，否则未消费完的任务会丢失
sync.Pool 和 errgroup.Group 的适用边界
这两个工具常被误用，关键要分清它们解决的问题不同：
-
sync.Pool只适合固定大小的小对象复用（如[]byte、bytes.Buffer），池化大对象（>1MB）等于手动制造内存泄漏，因为 GC 不会清理池中对象 -
errgroup.Group的价值不在“并发”，而在“错误传播”和“上下文联动”；如果所有 I/O 操作没传ctx（比如http.Client.Do(req.WithContext(ctx))），那eg.Wait()的取消就是假的 - 别为了用而用：简单循环用
for range+WaitGroup更清晰；只有当需要“任一失败即全停”或“统一超时”时，errgroup.Group才值得引入
最容易被忽略的是：goroutine 泄漏往往不发生在业务代码，而藏在第三方库的回调、未关闭的 timer、或 channel 发送端未被接收的死锁里。上线前跑一次 go tool pprof -http=:8080 binary 看 goroutine profile，比加一百行日志更管用。
