使用带缓冲的channel可限制Goroutine数量，通过容量为N的struct{}类型channel作为信号量，每启动一个goroutine写入值，结束时读出，确保最多N个并发执行。
在 Golang 中，Goroutine 虽然轻量，但如果无限制地创建，可能导致系统资源耗尽、调度开销增加甚至程序崩溃。因此，控制 Goroutine 数量是编写稳定并发程序
的关键。常见的做法是通过限流机制来管理并发任务的数量，确保系统在可控负载下运行。
使用带缓冲的 Channel 实现最大并发控制
最常见且简单的方式是使用带缓冲的 channel 作为信号量，控制同时运行的 Goroutine 数量。
定义一个容量为 N 的 channel，在每个 Goroutine 启动前写入一个值，执行完后读出，从而保证最多只有 N 个 Goroutine 并发运行。
func worker(id int, task string, sem chan struct{}) {
defer func() { <-sem }() // 任务完成释放信号
fmt.Printf("Worker %d 执行任务: %s\n", id, task)
time.Sleep(time.Second) // 模拟处理时间
}
func main() {
tasks := []string{"task1", "task2", "task3", "task4", "task5"}
maxConcurrency := 3
sem := make(chan struct{}, maxConcurrency)
for i, task := range tasks {
sem <- struct{}{} // 占用一个槽位，超了会阻塞
go worker(i+1, task, sem)
}
// 等待所有任务完成（这里简化处理，实际可用 WaitGroup）
time.Sleep(6 * time.Second)}
这种方式简洁有效，适合大多数场景下的并发数限制。
结合 WaitGroup 精确控制生命周期
上面的例子用了 Sleep 来等待，不精确。更规范的做法是配合 sync.WaitGroup 使用，确保主协程能准确等待所有任务结束。
func main() {
tasks := []string{"task1", "task2", "task3", "task4", "task5"}
maxConcurrency := 2
sem := make(chan struct{}, maxConcurrency)
var wg sync.WaitGroup
for i, task := range tasks {
wg.Add(1)
go func(id int, t string) {
defer wg.Done()
sem <- struct{}{}
defer func() { <-sem }()
fmt.Printf("Worker %d 处理: %s\n", id, t)
time.Sleep(time.Second)
}(i+1, task)
}
wg.Wait() // 等待全部完成
fmt.Println("所有任务结束")}
WaitGroup 确保了主流程不会提前退出，channel 控制了并发度，二者结合是生产级常用模式。
使用第三方库进行高级限流（如 semaphore 或 runner）
对于更复杂的场景，比如需要超时控制、优先级或动态调整并发数，可以使用 golang.org/x/sync/semaphore。
它提供了加权信号量，支持上下文超时，更适合精细控制。
import "golang.org/x/sync/semaphore"func main() { tasks := []string{"t1", "t2", "t3", "t4", "t5"} sem := semaphore.NewWeighted(2) // 最大并发 2 var wg sync.WaitGroup
for i, task := range tasks { wg.Add(1) go func(id int, t string) { defer wg.Done() sem.Acquire(context.Background(), 1) // 获取许可 defer sem.Release(1) // 释放 fmt.Printf("Worker %d 执行: %s\n", id, t) time.Sleep(time.Second) }(i+1, task) } wg.Wait()}
semaphore 支持上下文，可设置 Acquire 超时，适合网络请求等可能卡住的场景。
避免 Goroutine 泄露的关键点
无论用哪种方式，都要注意防止 Goroutine 泄露：
- 确保每个启动的 Goroutine 都能正常退出，尤其是在错误路径上也要释放信号量。
- 避免因 channel 阻塞导致 Goroutine 无法结束。
- 对可能 panic 的逻辑使用 defer 恢复，并释放资源。
例如，在 worker 中加入 recover：
defer func() {
if r := recover(); r != nil {
fmt.Printf("Goroutine panic: %v\n", r)
}
<-sem
}()
基本上就这些。通过 channel 信号量或 x/sync/semaphore，配合 WaitGroup 和 defer，就能安全有效地控制 Goroutine 数量，实现稳定的并发任务调度。关键是不让并发失控，也不让主流程提前退出。不复杂但容易忽略细节。
