应使用带缓冲的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
}

注意闭包捕获 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 泄漏。这些不会立刻报错，但压测时会暴露。