不能无限制启动 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 缓冲区共同构成资源水位线。调一个而不动其他，等于只关一扇窗却开着整面墙。
