Golang如何限制函数并发执行的数量？信号量与带缓冲通道【方法】-Golang-PHP中文网

推荐使用 sync.semaphore（go 1.21+）或 golang.org/x/sync/semaphore（旧版本），因其安全、可中断、panic 友好；手写 make(chan struct{}, n) 虽轻量但易因漏 defer 导致卡死。

golang如何限制函数并发执行的数量？信号量与带缓冲通道【方法】

直接用 sync.Semaphore（Go 1.21+）或 golang.org/x/sync/semaphore（旧版本），比手写带缓冲通道更安全、可中断、panic 友好；若只是简单脚本且兼容老版本，make(chan struct{}, N) 能用，但漏 defer 就卡死。

sync.Semaphore 是标准库原生支持的加权信号量，专为并发数限制设计，不依赖外部包，且自动处理上下文取消和 panic 安全释放。

初始化必须传 int64：如 sem := semaphore.NewWeighted(int64(5))，传 0 或负数会 panic
获取许可必须检查错误：if err := sem.Acquire(ctx, 1); err != nil，常见错误是 context.DeadlineExceeded 或 context.Canceled
释放必须配对且用 defer：defer sem.Release(1)，否则 panic 或提前 return 会导致令牌永久泄漏
别在 handler 内部重复 new semaphore——它应是全局单例，生命周期与服务一致

Go 1.20 及更早版本没有 sync.Semaphore，此时应使用官方维护的 golang.org/x/sync/semaphore，行为和接口几乎一致，只是需手动安装：

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

执行 go get golang.org/x/sync/semaphore
初始化：sem := semaphore.NewWeighted(5)（注意这里参数是 int64，但 Go 1.20 不强制类型转换，仍建议显式写 int64(5)）
Acquire 和 Release 的调用逻辑与标准库完全相同，同样必须 defer Release
若要快速失败（不等、不阻塞），可用 sem.TryAcquire(1)，返回 bool，适合限流后直接返回 HTTP 429 场景

所有 Go 版本都支持，零依赖，但极易出错。它本质是把 channel 当作“许可证池”，容量即最大并发数，struct{} 零内存开销且语义清晰。

初始化：sem := make(chan struct{}, 3) 表示最多 3 个任务并发
获取许可：sem （阻塞直到有空位），**不能用 <code>select + default 替代，否则可能跳过限流**
释放许可：，**必须放在 <code>defer 中，且 defer 必须在 goroutine 内部注册**，闭包变量如 i 要显式传参，否则所有 goroutine 共享同一个值
别用 len(sem) 判断是否可进——它返回已占用数，不是剩余数；真正可用的是 cap(sem) - len(sem)，但一般没必要查
绝对不要 close(sem)，后续读写都会 panic；也不要用 chan int 或 chan bool，纯属浪费内存和混淆语义

很多人把信号量放在 goroutine 启动前或 for 循环外，结果只限制了 goroutine 创建速度，实际 http.Client 并发请求数仍爆表。真正有效的限流点只有一个：

每个请求的 goroutine 内部、http.NewRequest() 之后、client.Do() 之前
即使请求失败、超时或 panic，也要归还许可——defer 正好覆盖这个逻辑
别混淆 http.Transport.MaxConnsPerHost：它管连接复用，不等于并发请求数；设成 5 却开 20 并发，只会让 15 个请求排队等连接，延迟放大且掩盖瓶颈
如果任务本身支持 context（如 client.Do(req.WithContext(ctx))），记得把同一个 ctx 传给 Acquire 和业务逻辑，确保取消能同时作用于调度层和执行层