Go并行计算需按CPU核心数切块并用固定worker池，避免盲目启goroutine导致调度风暴；任务量远小于核心数时应直接串行，chunkSize向上取整且防越界，配合带缓冲channel与正确close机制保障高效稳定执行。
Go 的并行计算不是“开越多 goroutine 越快”，而是靠合理拆分 + 固定 worker + 正确同步来榨干 CPU。盲目用 go f() 处理成千上万任务，大概率导致调度风暴、内存暴涨、GC 频繁，反而比串行还慢。
怎么拆分任务才不浪费 CPU 核心
任务拆分不能按“每个元素一个 goroutine”，而要按逻辑 CPU 核心数切块。用 runtime.NumCPU() 获取真实可用核心数，再算 chunk size：
-
chunkSize := (len(data) + numWorkers - 1) / numWorkers—— 向上取整，避免最后一块过小 - 若数据量远小于核心数（比如只有 10 个数但有 16 核），直接串行更省事；强行并行会因调度开销得不偿失
- 注意边界：
end := min(start+chunkSize, len(data))，防止索引越界
为什么必须用 Worker Pool 而不是直接 go launch
直接为每个任务起 goroutine，等于把调度压力甩给 runtime。当任务数达数千，goroutine 数可能突破 10k，pprof 里能看到 runtime.findrunnable 占比飙升，CPU 全花在找谁该运行上。
- 固定数量 worker（通常设为
runtime.NumCPU()）复用 goroutine，避免反复创建销毁开销 - 用带缓冲的
chan Task做任务队列，缓冲大小建议设为任务总数或稍大（如 100～1000），避免 sender 阻塞 - worker 内部用
for task := range tasks消费，关闭 channel 后自动退出，不泄漏
WaitGroup 和 channel 该怎么选来收结果
两者不互斥，但用途不同：WaitGroup 保“任务执行完”，channel 保“结果可取”。混用时最容易漏掉 close 或死锁。
立即学习“go语言免费学习笔记（深入）”；
- 如果只关心是否全部完成（无返回值），用
sync.WaitGroup就够：wg.Add()在发任务前，wg.Done()在 worker 结尾 - 如果要汇总结果，用
chan Result，但务必在所有 worker 返回后close(resultCh)，否则range resultCh永不结束 - 别在 worker 里直接写
resultCh 后不加缓冲——若主 goroutine 还没开始读，channel 会阻塞整个 worker
runtime.GOMAXPROCS 还需要手动设吗
Go 1.5+ 默认已设为 runtime.NumCPU()，但容器环境或旧部署可能仍卡在 1。不检查就假设“已开多核”，是线上 CPU 利用率长期不满 100% 的常见原因。
- 启动早期加一行：
runtime.GOMAXPROCS(runtime.NumCPU())，别依赖默认 - 不要设得比物理核心数还高（超线程可 +1，但别 +4）；GOMAXPROCS > 实际并发能力只会加剧上下文切换
- 可通过
debug.ReadGCStats或pprof观察schedlatency，若平均调度延迟 > 100μs，说明 GOMAXPROCS 或 worker 数已超负荷
真正卡住性能的，往往不是算法本身，而是 goroutine 启动时机、channel 缓冲大小、结果收集方式这些细节。哪怕只差一个 close() 或少调一次 wg.Done()，程序就可能 hang 在生产环境里半天不动。
