因为sync.waitgroup只计数goroutine数量，不感知任务权重，无法按cpu/io开销调度或限流；需用semaphore管理资源槽位、waitgroup仅等待结束，acquire/release配对控制权重占用，并注意acquire失败时wg.done()必须确保执行。
为什么不能直接用 sync.WaitGroup 控制带权重的并发？
因为 sync.WaitGroup 只计数 goroutine 数量，不感知任务“重量”。比如一个耗时 100ms 的重任务和 10 个各耗时 1ms 的轻任务，都只算作 1 次 Add(1)，无法按 CPU/IO 权重做调度或限流——它本质是“数量同步器”，不是“资源协调器”。
用 semaphore + WaitGroup 组合实现加权并发控制
核心思路：把“权重”转为“信号量占用单位数”，用 golang.org/x/sync/semaphore 管理资源槽位，sync.WaitGroup 仅负责等待所有 goroutine 结束。
- 每个任务执行前调用
sem.Acquire(ctx, weight)，阻塞直到获得足够槽位 - 任务结束后调用
sem.Release(weight)归还槽位 -
WaitGroup仍用于主协程等待全部完成，但不再参与权重逻辑 - 注意：权重应为正整数，且需预估最大并发总权重（即信号量容量），例如设为
100表示最多允许总权重 ≤ 100 的任务同时运行
示例片段：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
sem := semaphore.NewWeighted(100)
var wg sync.WaitGroup
for _, task := range tasks {
wg.Add(1)
go func(t Task) {
defer wg.Done()
ctx := context.Background()
if err := sem.Acquire(ctx, int64(t.Weight)); err != nil {
return // 被取消
}
defer sem.Release(int64(t.Weight))
t.Run()
}(task)
}
wg.Wait()
权重值怎么定才合理？别硬套 CPU 核心数
权重不是物理资源映射，而是相对开销估算。实际中建议：
- 以最轻任务为基准（权重 = 1），其他任务按其预期耗时/内存/IO 次数倍数向上取整
- 避免过大权重（如 >1000），否则单个任务长期独占信号量，导致饥饿
- 如果任务类型差异极大（如 DB 查询 vs JSON 解析），可分组使用不同信号量，而非强行统一权重
- 上线后通过监控观察实际并发分布，动态调整权重比——比如发现某类任务平均耗时翻倍，就将其权重 ×2
常见坑：Acquire 失败时忘记 Done 导致 WaitGroup 卡死
这是高频错误。一旦 sem.Acquire 返回 error（如 context canceled），goroutine 仍执行了 wg.Add(1)，但没走到 wg.Done()，最终 wg.Wait() 永远不返回。
- 必须把
wg.Done()放在 defer 最外层，或确保所有退出路径都调用它 - 更稳妥写法是：先
defer wg.Done()，再尝试Acquire，失败直接 return - 不要在
Acquire前做任何可能 panic 的操作，否则 defer 不触发
正确结构：
go func(t Task) {
wg.Add(1)
defer wg.Done() // 先放这里！
if err := sem.Acquire(ctx, int64(t.Weight)); err != nil {
return
}
defer sem.Release(int64(t.Weight))
t.Run()
}(task)
权重本身没有标准答案，关键是在任务提交前能估算出相对开销，并让信号量容量与系统承载力匹配。实际压测时，比理论值更重要的是看 P99 延迟和错误率是否突增——那往往意味着权重配比或总容量设错了。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
