会，而且降低得非常明显——不是“可能变慢”，而是“必然变慢”，甚至直接触发 OOM 崩溃；当 runtime.NumGoroutine() 超过 10 万时调度器严重过载，goroutine 过多导致上下文切换激增、GC 压力陡升、内存非线性增长，并易出现“too many open files”或“out of memory”错误；推荐用 make(chan struct{}, N) 实现信号量限流，IO 密集型设 50–200，CPU 密集型 ≤ runtime.NumCPU()，且必须 defer 归还令牌以防泄漏。
会，而且降低得非常明显——不是“可能变慢”，而是“必然变慢”，甚至直接触发 OOM 崩溃。
runtime.NumGoroutine() 超过 10 万时，调度器已严重过载
Go 的 goroutine 虽轻量（初始栈仅 2KB），但每个仍需维护调度元数据、栈空间、GC 标记开销。当 runtime.NumGoroutine() 持续高于 CPU 核心数的 100 倍（例如 64 核机器上超 6400 个），调度器就会陷入“找 goroutine 比执行还费劲”的状态。
- 上下文切换频率激增，
runtime.scheduler成为 CPU 热点（pprof 可见） - GC 压力陡升：大量 goroutine 持有临时对象，导致 STW 时间延长、分配速率飙升
- 内存占用非线性增长：一个 goroutine 平均实际占用 4–8KB（含栈+调度结构），10 万个即 400MB+，不计业务数据
- 常见错误现象：
http: Accept error: accept tcp: too many open files或runtime: out of memory
用 make(chan struct{}, N) 实现信号量控制最简单可靠
这是生产环境最常用、零依赖、语义清晰的并发限流方式，比引入 golang.org/x/sync/semaphore 更轻量，也比 errgroup.WithContext 更底层可控。
- 容量
N应根据任务类型设定：IO 密集型（如 HTTP 请求、数据库查询）可设为 50–200；CPU 密集型（如图像压缩、JSON 解析）建议 ≤runtime.NumCPU() - 必须配合
defer归还令牌，否则会永久泄漏：
sem := make(chan struct{}, 10)
for _, task := range tasks {
sem <- struct{}{} // 获取令牌（阻塞直到有空位）
go func(t Task) {
defer func() { <-sem }() // 必须归还！不可省略
doTask(t)
}(task)
}- 切忌在循环外一次性填满 channel（如
for i := 0; i ），这会失去动态排队能力
worker pool 模式比裸启 goroutine 更适合批量任务
当你需要处理成百上千个独立任务（如日志解析、消息消费、爬虫 URL 队列），go func() { ... }() 直接启动是最大陷阱——它等于把调度压力全甩给 runtime。
立即学习“go语言免费学习笔记（深入）”；
- worker pool 的核心是「固定数量 goroutine + 无界/有界任务 channel」，复用执行单元，避免创建销毁开销
- 任务 channel 必须带缓冲（如
chan Task容量设为 100～1000），否则发送端易阻塞，反向拖垮上游 - 务必用
context.Context控制 worker 生命周期，防止任务卡死导致 worker 永久挂起
典型结构：
tasks := make(chan Task, 100)
for i := 0; i < 8; i++ { // 启动 8 个 worker
go worker(tasks, ctx)
}
// 发送任务（非阻塞）
for _, t := range batch {
select {
case tasks <- t:
case <-ctx.Done():
return
}
}别忽略 context.WithTimeout 和 select 的组合防御
并发控制不能只防“多”，更要防“久”——单个 goroutine 卡住 30 秒，就等于占着一个并发名额白耗资源。
- 所有外部调用（HTTP、DB、RPC）必须包裹
context.WithTimeout，超时时间应显著短于整体 SLA（如接口 SLA 是 2s，单次 DB 查询设为 800ms） - 在 goroutine 内部用
select监听ctx.Done()，而不是靠函数返回后才检查，确保中断即时生效 - 错误处理要区分
ctx.Err() == context.DeadlineExceeded和真实业务错误，避免将超时误判为失败重试
高频踩坑点：忘记在 defer 中关闭 HTTP body、未对 sql.Rows 调用 .Close()，这些都会让 goroutine 在系统调用层阻塞，绕过所有 context 控制。
