最稳妥方式是用 sync.WaitGroup + 带缓冲的 chan 收集并发结果；关键在于确保所有结果及时写入、不丢不 panic，避免无缓冲 channel 导致 goroutine 卡死。
用 sync.WaitGroup + chan 收集并发结果最稳妥
Go 里没有内置的“并发任务聚合”类型，但组合 sync.WaitGroup 和带缓冲的 chan 是最常用、最可控的方式。关键不是“怎么启动 goroutine”，而是“怎么确保所有结果都来得及写入、不丢不 panic”。
常见错误是直接往无缓冲 channel 写，又没配好接收协程，导致某个 goroutine 卡死在 ch —— 整个任务就 hang 住。
- channel 必须带缓冲，容量至少等于任务数（或预估最大结果数），避免发送阻塞
-
WaitGroup的Add要在 goroutine 启动前调用，不能放在 goroutine 里 - 每个 goroutine 结束前必须调用
wg.Done()，推荐用defer wg.Done() - 主 goroutine 调用
wg.Wait()后再关闭 channel，否则接收端可能漏数据或 panic
select + time.After 防止无限等待
真实场景中，部分任务可能因网络超时、死循环卡住，不能让整个结果收集永远等下去。靠 select 控制超时是 Go 的惯用法。
别只对单个 channel 做超时判断；要在收集循环里对 resultChan 和 time.After 同时 select，否则即使超时了，还在等未完成的 goroutine 写 channel。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 启动 goroutine 前记录开始时间，或统一用
context.WithTimeout管理生命周期 - 接收结果时用
for i := 0; i + <code>select，而不是range ch（后者依赖 close，而 close 又依赖所有 goroutine 完成） - 超时后可主动调用
cancel()中断还在运行的 goroutine（如果它们支持 context）
用 errgroup.Group 简化错误传播和等待
当任务之间有依赖、或任意一个失败就要整体失败时，golang.org/x/sync/errgroup 比裸写 WaitGroup 更安全。它自动处理 panic 捕获、错误短路、以及等待逻辑。
注意：它的 Go 方法内部已封装了 WaitGroup 行为，你不需要也不应该再手动调用 Done()；但结果仍需自己通过闭包变量或 channel 收集。
- 所有任务共享同一个
errgroup.Group实例，不要在循环里反复 new - 若需收集结果，建议搭配局部 slice + mutex，或更推荐：每个任务把结果发到同一个带缓冲 channel（
errgroup不干涉这个） - 它默认不支持超时，要加超时得配合
ctx, cancel := context.WithTimeout(...)传入eg.Go
切忌用全局 map + sync.Mutex 存结果
看起来简单，实际容易出问题：比如多个 goroutine 并发写 map 导致 panic（Go 运行时会直接 crash），或忘记加锁 / 锁粒度太大拖慢性能。
map 并发读写是 runtime 层面禁止的，哪怕只读+写混合也不行。用 sync.Map？它适合读多写少、key 生命周期长的缓存场景，不适合一次性的任务结果汇总——接口笨重、没法遍历、还带额外内存开销。
- 真要用 map，必须全程配
sync.RWMutex，且读写都要加锁（RWMutex的读锁只对纯读有效） - 更轻量的做法是：每个 goroutine 把结果写进自己的 struct 或 slice，最后由主 goroutine 合并
- 如果结果结构复杂、字段多，优先考虑 channel 发送指针（
ch ），避免拷贝开销
真正难的不是“怎么并发”，而是“怎么定义‘结果已就绪’”——是写完就算，还是必须校验？是否允许部分失败？这些业务语义决定了 channel 缓冲大小、是否需要二次过滤、要不要区分成功/失败通道。别过早抽象成通用“结果收集器”，先让具体任务跑通、压测、看丢不丢数据。
