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，会永久阻塞。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- worker 数量 = 并发上限，硬编码或配置化都行，别动态伸缩（除非你真需要）
- 任务 channel 类型要具体，比如
chan string，别用interface{}增加类型断言开销 - worker 内部用
select+default可做非阻塞尝试，但批量队列一般不需要；重点是用<-ch阻塞取任务
tasks := make(chan string, 100)
wg.Add(5) // 5 个 worker
for i := 0; i < 5; i++ {
go func() {
defer wg.Done()
for task := range tasks { // channel 关闭后自动退出
process(task)
}
}()
}
// 发送任务
for _, t := range allTasks {
tasks <- t
}
close(tasks) // 必须关闭，否则 worker 永远卡在 range
wg.Wait()
为什么别直接用 runtime.GOMAXPROCS 控制并发数
runtime.GOMAXPROCS 控制的是 OS 线程数上限，不是 goroutine 并发数。设成 1 不会让 goroutine 串行执行，只是限制了能并行运行的 OS 线程数——goroutine 调度仍由 Go runtime 自动管理，大量 goroutine 还是会并发抢占。想限流，得靠 channel 缓冲或信号量。
典型误用是看到 CPU 占用高就调小 GOMAXPROCS，结果发现任务延迟反而更大，因为调度器被迫更频繁切换，且 IO 密集型任务根本不受它影响。
-
GOMAXPROCS默认等于 CPU 核心数，多数情况不用改 - IO 密集任务（HTTP、DB）完全不依赖它，goroutine 会在等待时自动让出
- 真要压测或调试调度行为才临时调整，上线环境别碰
怎么用 semaphore（信号量）做细粒度并发控制
Go 标准库没提供信号量，但用 chan struct{} 一行就能实现。它比 channel 分发更轻，适合“每次只允许 N 个 goroutine 进入临界区”的场景，比如限制数据库连接、API 调用频次、文件句柄占用。
注意别把信号量 channel 当任务队列用：它不存数据，只做通行许可；而且必须确保每个 <-sem 都配对 sem <- struct{}{}，漏了就会死锁。
- 初始化：
sem := make(chan struct{}, 3)表示最多 3 个并发 - 进入前：
sem <- struct{}{}（阻塞直到有空位） - 退出后：
<-sem（释放一个位置，必须执行） - 别用
len(sem)判断剩余容量，它是瞬时值，不可靠
sem := make(chan struct{}, 5)
for _, task := range tasks {
go func(t string) {
sem <- struct{}{} // 获取许可
defer func() { <-sem }() // 保证释放，defer 在这里比显式调用更稳妥
process(t)
}(task)
}
实际写的时候，WaitGroup 和 chan 组合最常用；信号量只在需要精确控制资源占用时才上。别为了“看起来高级”而套模板，先想清楚你要控的是“任务总数”“并发数”还是“资源配额”。
