应使用带缓冲的channel安全收集goroutine返回值；声明如make(chan int, 10)，容量不小于预期结果数，各goroutine计算完立即发送结果至channel。
goroutine 启动后如何安全收集返回值
直接用局部变量接收多个 goroutine 的结果必然出错——每个协程写同一变量会竞态。必须用同步机制传递结果，最常用的是 channel。
- 声明带缓冲的
chan（如make(chan int, 10)），容量至少等于预期结果数，避免发送阻塞 - 每个
goroutine计算完立即ch ，不要在协程外等全部启动后再读 - 主 goroutine 用
for i := 0; i 按需收数据，不依赖执行顺序 - 切勿用
range ch除非你已关闭 channel；否则主 goroutine 可能提前退出，漏掉未发送的结果
聚合时如何避免 WaitGroup 和 channel 混用导致死锁
常见错误是：用 sync.WaitGroup 等待所有 goroutine 结束，同时又用 range ch 读 channel —— 若某个 goroutine panic 或未发送，range 会永远卡住。
- 只选一种同步方式：推荐纯 channel 方案（更符合 Go 并发哲学）
- 若坚持用
WaitGroup，务必在每个 goroutine 末尾调用wg.Done()，且确保wg.Wait()在关闭 channel 之后 - 关闭 channel 的责任应由**启动 goroutine 的那一方**承担（通常是主 goroutine），在
wg.Wait()返回后调用close(ch) - 读 channel 时用
for v := range ch才安全，前提是 channel 已被正确关闭
多个数据源并发拉取并聚合的典型结构
比如从 3 个 API 接口并发获取用户统计，再求总和。关键不是“怎么开 goroutine”，而是“怎么组织输入/输出边界”。
func fetchAndSum(urls []string) (int, error) {
ch := make(chan int, len(urls))
var wg sync.WaitGroup
for _, url := range urls {
wg.Add(1)
go func(u string) {
defer wg.Done()
resp, err := http.Get(u)
if err != nil {
return
}
defer resp.Body.Close()
// 解析 JSON 得到 count 字段 → 假设为 n
ch <- n
}(url)
}
go func() {
wg.Wait()
close(ch)
}()
total := 0
for n := range ch {
total += n
}
return total, nil}
立即学习“go语言免费学习笔记（深入）”；
- 注意闭包捕获
url时用go func(u string)传参，避免所有 goroutine 共享同一个循环变量 - HTTP 调用必须设超时（
http.Client{Timeout: 5 * time.Second}），否则单个慢接口拖垮整个聚合 - 如果某次请求失败，当前实现会跳过（
return），但调用方无法感知失败——需要改用chan struct{val int; err error}传递错误
聚合结果需要排序或去重时怎么办
channel 本身无序，且不能直接对 channel 做 sort 或 map 去重。必须先收全数据，再处理。
- 用切片暂存：
results := make([]int, 0, cap(ch))，然后for v := range ch { results = append(results, v) } - 去重用
map[int]struct{}，不是map[int]bool（虽可工作，但struct{}零内存更惯用） - 排序前确认切片非空，空切片传给
sort.Ints没问题，但若后续逻辑依赖长度，需显式检查 - 大数据量时慎用内存聚合：10 万条结果全 load 到内存再排序可能 OOM，此时应考虑流式处理（如分批写入临时文件再归并）
实际写聚合逻辑时，最容易被忽略的是错误传播路径和资源清理时机——比如 HTTP body 没 close、channel 关闭过早、goroutine 泄漏。这些不会立刻报错，但压测时会暴露。
