sync.WaitGroup 无法获取 goroutine 返回值，因其本身不支持返回；需配合通道或共享内存收集结果，推荐用带缓冲通道与单独 collector 协程安全聚合。
为什么 sync.WaitGroup 不能直接等 goroutine 返回值
很多人一上来就用 sync.WaitGroup 启动一堆 goroutine，以为 wg.Wait() 之后就能拿到所有结果——但实际只能同步执行完成，无法捕获返回值。根本原因是 goroutine 本身不支持“返回”，它没有返回值类型，更不会把结果自动塞进某个变量里。
正确做法是配合通道（chan）或共享内存（如切片 + sync.Mutex）来收集结果。通道更符合 Go 的并发哲学，也更容易避免竞态。
- 别在 goroutine 里直接修改全局切片，不加锁必出
fatal error: concurrent map writes或数据丢失 - 如果聚合逻辑简单（比如求和、计数），优先用无缓冲通道 + 单独 collector goroutine
- 若需保留原始顺序或做复杂合并（如 map[string][]int），建议用带缓冲的通道，并控制并发数防止内存爆炸
用 chan + sync.WaitGroup 安全聚合结构体数据
假设你要并发请求多个 API，每个返回 type Result struct { ID int; Value float64 }，最后按 ID 汇总 Value 总和。关键不是“怎么开 goroutine”，而是“怎么让结果不丢、不错、不乱”。
示例核心逻辑：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
results := make(chan Result, len(urls)) // 缓冲长度 = 任务数，防阻塞
var wg sync.WaitGroup
<p>for _, url := range urls {
wg.Add(1)
go func(u string) {
defer wg.Done()
r := fetchFromURL(u) // 假设这个函数返回 Result
results <- r
}(url)
}</p><p>go func() {
wg.Wait()
close(results) // 所有 goroutine 结束后关闭通道
}()</p><p>// 主协程收结果
var sum float64
for r := range results {
sum += r.Value
}
- 必须在单独 goroutine 中调用
wg.Wait()后close(results)，否则range会永远阻塞 - 缓冲通道大小设为
len(urls)是为了确保所有结果都能立刻写入，避免 sender 协程因通道满而卡住 - 如果
fetchFromURL可能 panic，需加recover，否则整个程序崩溃且wg.Done()不会被执行
当聚合需要中间状态（如分组统计）时，该不该用 sync.Map
比如你不是简单求和，而是要把结果按 Category 字段分组，每组存一个 []float64。这时有人直觉用 sync.Map，但其实多数场景下没必要——sync.Map 适合读多写少、key 动态增删的场景；而聚合阶段通常是固定 key（如预定义的 category 列表），写一次、读多次。
- 更轻量的做法：用普通
map[string][]float64+sync.Mutex，在 collector goroutine 里统一加锁写入 - 如果 category 数量极大（上万）、且写入分散，才考虑
sync.Map，但要注意它的LoadOrStore不保证原子性拼接切片，仍需额外同步 - 千万别在每个 goroutine 里对同一个
sync.Map的 value 做append——因为append可能分配新底层数组，导致其他 goroutine 看不到更新
超时控制和错误聚合常被忽略的细节
真实业务中，单个子任务失败不能让整个聚合失败，但也不能完全忽略。常见错误是只检查 err != nil 就跳过，却不记录或限流重试，最终导致结果偏差却无感知。
- 用
context.WithTimeout包裹每个子任务，避免某个慢接口拖垮整体 - 错误要分类：网络超时可重试，解析失败应记录并跳过，认证失败则整个流程应提前终止
- 聚合结果里建议附带元信息，比如
type AggResult { Sum float64; Count int; Failed []string }，而不是只返回数字 - 如果使用
errgroup.Group，注意它默认不收集非第一个错误；如需全部错误，得自己维护[]error并加锁写入
聚合逻辑越靠近业务，就越容易在并发边界上出问题——不是语法错，而是时机错、顺序错、所有权错。这些地方没法靠单元测试全覆盖，得靠对 channel 关闭时机、锁粒度、context 生命周期的肌肉记忆。
