结论是：用 runtime.gomaxprocs + 分片 + sync.waitgroup 手动调度处理大数组计算最稳最快；因 go 默认 gomaxprocs=1（尤其容器/嵌入式中），goroutine 仅协作调度而非并行，需显式设为 numcpu() 并分片避免 channel 锁开销、隐式阻塞和 goroutine 泛滥。
直接说结论：别用通用“并行框架”，用 runtime.GOMAXPROCS + 分片 + sync.WaitGroup 手动调度，才是处理大数组计算最稳、最快的方式。
为什么 goroutine 默认不并行跑大数组
Go 运行时默认只绑一个 OS 线程（GOMAXPROCS=1），所有 goroutine 在单线程上协作调度。哪怕你启 100 个 goroutine 做整数加法，top 也只看到 100% CPU 占用（单核满载），不是真正的并行。
- Go 1.5+ 虽默认设为 CPU 核数，但容器、嵌入式环境或被其他代码覆盖后仍可能为 1
- 必须在
main()开头显式调用runtime.GOMAXPROCS(runtime.NumCPU()) - 用
runtime.GOMAXPROCS(0)可读当前值，建议日志打出来验证
分片计算比 channel 收集快得多
对大数组（比如百万级 []int64 求和、转换、过滤），用无缓冲 chan 收集每个 goroutine 的结果，会引入锁竞争和内存拷贝开销——实测万级以上吞吐下降 20%+。
- 预分配结果切片（如
results := make([]int, len(data))），按索引写入，避免 map 并发写 panic - chunkSize 计算用
(len(data) + workers - 1) / workers向上取整，保证末尾不丢数据 - 闭包传参必须显式捕获
start/end，不能直接用循环变量i，否则所有 goroutine 共享同一份值
避免阻塞导致并行失效
CPU 密集任务里一旦出现隐式阻塞（如 fmt.Println、time.Sleep、文件读写、未超时的 HTTP 调用），goroutine 就会让出 P，但不会触发新 M 启动，其余 worker 只能干等。
- pprof 显示大量
runtime.mcall或runtime.gopark？说明调度器在频繁干预，不是并行，是“假并发” - 纯计算逻辑里禁用任何 syscall、I/O、锁等待；中间日志用 buffered writer 或批量 flush
- 若需同步状态，优先用
channel配select+ctx.Done()，而不是sync.Mutex配cond.Wait()
固定 worker 数比“开一堆 goroutine”更可控
worker 数设为 runtime.NumCPU() 是黄金法则。设太高（如 100）反而增加调度负担；设太低（如 1）等于没并行。
- 不要用
for range data { go f(item) }这种模式——内存暴涨、goroutine 泄漏、结果难收集 - 聚合类操作（如统计频次）务必局部计算（每个 worker 用独立
map[string]int），最后单次加锁合并 - 如果输入是流式数据（非一次性加载的大 slice），才考虑用带 buffer 的
chan+ context 控制生命周期
真正卡住性能的，往往不是算法本身，而是没切断 goroutine 和 P 的绑定、没管住 channel 的锁开销、或者让计算逻辑悄悄掉进系统调用——这些细节一错，再多的“框架”也救不回来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
