sync.waitgroup 用于同步多个协程执行：主协程调用 add(n) 预设任务数，每个协程完成时调用 done()，主协程通过 wait() 阻塞等待全部完成；关键要求是 add 必须在 goroutine 启动前调用，done 必须确保执行（避免仅依赖 defer）。
怎么用 sync.WaitGroup 控制多协程批量执行队列
直接用 sync.WaitGroup 是最轻量、最可控的方式，不用引入第三方库也能精准等所有任务结束。它不负责调度或限流，只做“计数+阻塞等待”，适合你明确知道任务总数、且希望主协程同步收尾的场景。
常见错误是 Add() 调用时机不对：必须在启动 goroutine 之前调用，否则可能漏计数或 panic；另外 Done() 必须在每个 goroutine 结束前调用，不能靠 defer（万一 panic 没触发 defer 就漏了）。
-
WaitGroup.Add(n)要在 for 循环外或循环开始前一次性加总数量，别在 goroutine 里加 - 每个 goroutine 执行完逻辑后，立刻调用
wg.Done()，不要依赖 defer（尤其当有 recover 或提前 return 时） - 主 goroutine 中用
wg.Wait()阻塞，不是轮询或 sleep
var wg sync.WaitGroup
tasks := []string{"task1", "task2", "task3"}
wg.Add(len(tasks))
for _, t := range tasks {
go func(task string) {
defer wg.Done() // 这里用 defer 是安全的，因为函数体简单无 panic 风险；但复杂逻辑建议显式调用
process(task)
}(t)
}
wg.Wait() // 主协程卡在这里，直到全部完成
怎么用 chan + select 实现带缓冲的批量任务队列
如果任务来源持续不断（比如从 HTTP 请求、文件读取、消息队列来），且你想控制并发数（比如最多 5 个 goroutine 同时跑），就得用 channel 做任务分发。核心是：一个输入 channel 接任务，固定数量 worker 从它取，再用 sync.WaitGroup 等 worker 全退出。
容易踩的坑是 channel 关闭时机不对：必须由生产者关闭，且要在所有任务发送完之后；worker 不能用 range 遍历未关闭的 channel，会永久阻塞。
- worker 数量 = 并发上限，硬编码或配置化都行，别动态伸缩（除非你真需要）
- 任务 channel 类型要具体，比如
chan string，别用interface{}增加类型断言开销 - worker 内部用
select+default可做非阻塞尝试，但批量队列一般不需要；重点是用阻塞取任务
tasks := make(chan string, 100) wg.Add(5) // 5 个 worker for i := 0; i <h3>为什么别直接用 <code>runtime.GOMAXPROCS</code> 控制并发数</h3><p><code>runtime.GOMAXPROCS</code> 控制的是 OS 线程数上限，不是 goroutine 并发数。设成 1 不会让 goroutine 串行执行，只是限制了能并行运行的 OS 线程数——goroutine 调度仍由 Go runtime 自动管理，大量 goroutine 还是会并发抢占。想限流，得靠 channel 缓冲或信号量。</p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill4918" title="Golang Spf13 Viper"><img src="https://img.php.cn/upload/skill/000/000/081/179025319165074.jpg" alt="Golang Spf13 Viper" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/skill4918" title="Golang Spf13 Viper" class="overflowclass">Golang Spf13 Viper</a> <p class="overflowclass">Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。</p> </div> <a rel="nofollow" href="/xiazai/skill4918" title="Golang Spf13 Viper" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div><p>典型误用是看到 CPU 占用高就调小 <code>GOMAXPROCS</code>，结果发现任务延迟反而更大，因为调度器被迫更频繁切换，且 IO 密集型任务根本不受它影响。</p>
-
GOMAXPROCS默认等于 CPU 核心数，多数情况不用改 - IO 密集任务（HTTP、DB）完全不依赖它，goroutine 会在等待时自动让出
- 真要压测或调试调度行为才临时调整，上线环境别碰
怎么用 semaphore（信号量）做细粒度并发控制
Go 标准库没提供信号量，但用 chan struct{} 一行就能实现。它比 channel 分发更轻，适合“每次只允许 N 个 goroutine 进入临界区”的场景，比如限制数据库连接、API 调用频次、文件句柄占用。
注意别把信号量 channel 当任务队列用：它不存数据，只做通行许可；而且必须确保每个 都配对 <code>sem ，漏了就会死锁。
- 初始化：
sem := make(chan struct{}, 3)表示最多 3 个并发 - 进入前：
sem （阻塞直到有空位） - 退出后：
（释放一个位置，必须执行） - 别用
len(sem)判断剩余容量，它是瞬时值，不可靠
sem := make(chan struct{}, 5)
for _, task := range tasks {
go func(t string) {
sem <p>实际写的时候，<code>WaitGroup</code> 和 <code>chan</code> 组合最常用；信号量只在需要精确控制资源占用时才上。别为了“看起来高级”而套模板，先想清楚你要控的是“任务总数”“并发数”还是“资源配额”。</p>golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
