goroutine 过多必然拖慢程序：调度器超载、内存激增、GC 停顿延长、OOM 风险上升；高频踩坑包括 HTTP handler 无节制启协程、循环中盲目并发、channel 消费端泄漏、超时未接 ctx.Done()；应选用 semaphore 或 worker pool 合理控并发。
goroutine 过多会直接拖慢程序，不是“可能”，而是必然——调度器扛不住、内存涨得快、GC 停顿变长，甚至悄无声息地 OOM。
为什么 goroutine 多了反而更慢？
Go 调度器（GMP 模型）虽高效，但每个 goroutine 都要记账：栈空间（初始约 2KB）、运行队列节点、状态机元数据。当数量从几千飙到几万，问题就不是“轻量”能掩盖的：
- 调度器需频繁扫描、迁移、唤醒 goroutine，
runtime.schedule()调用开销指数级上升 - 大量阻塞 goroutine（如等 channel、等锁、等网络响应）不释放 P，导致其他可运行 goroutine “饿死”
- 堆上临时对象暴增（尤其没配
sync.Pool），触发更频繁的 GC，STW时间拉长 - pprof 中
runtime.gopark和runtime.findrunnable占比飙升，是典型信号
哪些代码最容易触发 goroutine 泛滥？
不是写 go f() 就错，而是写在错误的位置 + 缺少约束。高频踩坑场景：
- HTTP handler 里每请求都
go process(r)，无任何限流或池化 - for 循环中无节制启动：
for _, item := range items { go handle(item) }（items 有 10 万条？瞬间 10 万个 goroutine） - channel 消费端未关闭，sender 不断发、receiver 却因 panic 或逻辑缺陷提前退出，goroutine 悬停泄漏
- 用
time.After或select等超时但没接ctx.Done()，导致 goroutine 卡在等待中无法取消
怎么控制并发数？别只靠 chan struct{} 手搓信号量
信号量（如 golang.org/x/sync/semaphore）和 worker pool 都有效，但适用场景不同：
立即学习“go语言免费学习笔记（深入）”；
- 简单粗粒度限流（比如最多 10 个 HTTP 后端调用并发）→ 用
semaphore.Weighted，Acquire(ctx, 1)+Release(1)清晰可控 - 任务有明确入队/出队、需复用协程、要支持优雅关闭 → 自建 worker pool 更稳，核心是：
for job := range jobsChan+defer wg.Done()+close(jobsChan)配合sync.WaitGroup - 千万别用无缓冲
chan struct{}做高并发信号量——它本质是同步点，所有 goroutine 争抢一个 channel，会引发严重调度竞争 - 缓冲 channel（如
make(chan struct{}, 10)）只是“假并发控制”，一旦缓冲满，就阻塞，实际并发数还是不可控
怎么确认是不是 goroutine 导致性能掉坑？
别猜，用工具看真实数字：
- 实时查数量：
runtime.NumGoroutine()打日志或暴露为 metric，突增就是警报 - 跑 pprof：
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=1查堆积在哪（常是chan receive或select） - 开 trace：
go tool trace看 Goroutine 的生命周期——有没有创建后永远不运行（parked forever）、有没有大量 goroutine 在同一时间点集体阻塞 - 加
GODEBUG=schedtrace=1000启动，观察调度器是否长期卡在findrunnable或steal
真正难的不是“加限制”，而是判断哪里该限、限多少。CPU 密集型任务通常不应超过 GOMAXPROCS，而 I/O 密集型可以更高，但上限必须基于压测数据定，不是拍脑袋设 100 或 1000。另外，goroutine 泄漏往往藏在 error path 里——panic 没 recover、channel 关闭逻辑被跳过、context 取消没监听，这些地方比主流程更值得盯紧。
