最直观的Go并发限流方式是用带缓冲的chan作许可证池，缓冲容量即最大并发数，每次goroutine启动前取值、结束后写回，配合sync.WaitGroup协调完成。
用 sync.WaitGroup + chan 做基础并发限流最直观
Go 里最轻量、最可控的限流方式，就是靠带缓冲的 chan 控制“同时运行的 goroutine 数量”。它不依赖第三方库，语义清晰，适合大多数场景。
核心思路：把 chan 当作“许可证池”，每次启动 goroutine 前先 take（从 chan 取一个值），执行完再 put（写回一个值）。缓冲区容量即最大并发数。
- 缓冲大小设为
N，就严格保证最多N个 goroutine 并发执行 - 阻塞发生在
ch ，而不是业务逻辑里，调度开销极小 - 注意别漏掉
defer归还令牌，否则会永久泄漏
func main() {
const maxConcurrent = 3
sem := make(chan struct{}, maxConcurrent)
<pre class="brush:php;toolbar:false;">var wg sync.WaitGroup
for i := 0; i <p>}</p>
用 golang.org/x/time/rate.Limiter 控制请求速率而非并发数
rate.Limiter 不是并发数限制器，而是「单位时间请求数」控制器（比如 QPS=10）。它基于令牌桶算法，适合 API 网关、下游服务防刷等场景，和上面的并发控制目标不同，别混用。
-
rate.NewLimiter(rate.Every(100*time.Millisecond), 1)表示每 100ms 最多放行 1 个请求（≈10 QPS） -
limiter.Wait(ctx)会阻塞直到拿到令牌；limiter.Allow()则立即返回 bool，适合非阻塞判断 - 注意：它不感知 goroutine 生命周期，只管“请求到达时间”，无法防止瞬时并发暴涨（比如 100 个 goroutine 同时调
Allow()，前b个会成功）
errgroup.Group
- 调用
eg.Go()启动任务，内部已处理 panic 捕获和 error 返回 - 传入的
context.Context被所有 goroutine 共享，任意一个 cancel 都会让其余等待中的sem 或limiter.Wait()失败 - 别直接用
eg.SetLimit(N)—— 它只限制 goroutine 启动速率，不控制实际并发数，容易误解
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
<p>sem := make(chan struct{}, 5)
eg, egCtx := errgroup.WithContext(ctx)</p><p>for i := 0; i </p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill8661" title="Golang Uber Dig"><img
src="https://img.php.cn/upload/skill/000/000/081/179215391842073.jpg" alt="Golang Uber Dig" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill8661" title="Golang Uber Dig" class="overflowclass">Golang Uber Dig</a>
<p class="overflowclass">使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等</p>
</div>
<a rel="nofollow" href="/xiazai/skill8661" title="Golang Uber Dig" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div><pre class="brush:php;toolbar:false;"> select {
case <p>}</p><p>if err := eg.Wait(); err != nil {
fmt.Printf("stopped early: %v\n", err)
}</p>
别忽略 runtime.GOMAXPROCS 和 GC 对限流效果的影响
限流逻辑本身再精确，也挡不住底层调度和内存压力带来的抖动。尤其在高并发短任务场景下，这两个点常被忽视：
-
GOMAXPROCS默认等于 CPU 核心数，但若大量 goroutine 频繁阻塞/唤醒（如密集 I/O），适当调高（比如runtime.GOMAXPROCS(16)）可减少调度排队延迟，让sem更快被释放 - 频繁创建小对象（如每个任务 new 一个 struct）会加剧 GC 压力，导致 STW 时间变长，间接拉长任务平均耗时，使限流“看起来”失效（比如设定 5 并发，但因 GC 卡顿，实际完成更慢）
- 验证方法：跑压测时用
go tool trace看 goroutine block 和 GC 时间占比，比单纯看 QPS 更准
限流不是加个 channel 就万事大吉。真正稳定，得盯住调度器行为、GC 日志、以及你用的到底是「控并发」还是「控速率」——这两者解决的问题完全不同，选错工具，后面调参都是白忙。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
