不能无限制启动 goroutine，因每个goroutine需约2KB栈内存且调度开销大，易致内存耗尽、上下文切换频繁、HTTP超时及DB连接池打满；可用带缓冲channel实现限流。

为什么不能无限制启动 goroutine

Go 的 goroutine 虽轻量，但每个仍需约 2KB 栈空间（可增长），大量并发会吃光内存；更关键的是，频繁调度、抢占、上下文切换本身会拖慢整体吞吐。常见现象是：代码看着“并发了”，实际 http.Client 超时变多、数据库连接池打满、context.DeadlineExceeded 错误突增——这往往不是 CPU 瓶颈，而是资源争用失控。

用带缓冲的 channel 实现最简限流器

这是最易理解、无第三方依赖的方案，本质是把“启动 goroutine”变成“从 channel 取令牌”的阻塞操作。

func runWithLimit(tasks []func(), maxConcurrent int) {
    sem := make(chan struct{}, maxConcurrent)
    for _, task := range tasks {
        sem <- struct{}{} // 阻塞直到有空位
        go func(t func()) {
            defer func() { <-sem }() // 释放令牌
            t()
        }(task)
    }
    // 等待所有 goroutine 结束（实际中建议用 sync.WaitGroup）
    for i := 0; i < len(tasks); i++ {
        <-sem
    }
}

注意点：

• sem 是带缓冲的 chan struct{}，容量即最大并发数
• 必须在 goroutine 内部 defer 释放令牌，否则 panic 或死锁
• 该写法不处理 panic：若 t() panic， 不会执行，令牌泄露

用 sync.WaitGroup + semaphore 库更稳妥

标准库没提供信号量，但 golang.org/x/sync/semaphore 是官方维护的可靠实现，支持带超时的获取、可取消、能统计当前使用量。

立即学习“go语言免费学习笔记（深入）”；

import "golang.org/x/sync/semaphore"
func runWithSemaphore(tasks []func(), maxConcurrent int) {
s := semaphore.NewWeighted(int64(maxConcurrent))
var wg sync.WaitGroup
for _, task := range tasks {
wg.Add(1)
go func(t func()) {
defer wg.Done()
if err := s.Acquire(context.Background(), 1); err != nil {
return // 如 context 被 cancel
}
defer s.Release(1)
t()
}(task)
}
wg.Wait()
}

优势：

• Acquire 支持 context.Context，可统一控制超时或取消
• Release 安全：即使 t() panic，defer 仍会执行
• 比手写 channel 更易扩展（比如动态调整权重、监控当前占用数）

HTTP 客户端等内置组件的并发控制别忽略

很多人只管自己启 goroutine，却忘了底层 HTTP 连接池默认不限制并发连接数，http.Transport.MaxIdleConnsPerHost 默认是 0（即不限），结果大量 goroutine 同时发请求，瞬间打爆服务端或本地文件描述符。

正确做法：

• 设置 http.Transport.MaxIdleConnsPerHost = 10（匹配你的 goroutine 限流数）
• 设置 http.Transport.MaxIdleConns = 100
• 为每个请求显式传入带超时的 context.WithTimeout
• 避免复用同一个 *http.Client 在不同限流策略下混用

goroutine 数量不是孤立参数，它和网络层、DB 连接池、磁盘 IO 缓冲区共同构成资源水位线。调一个而不动其他，等于只关一扇窗却开着整面墙。