不能直接用goroutine并发递归调用归并排序——因合并阶段有依赖和竞争，盲目并发会导致data race、调度过载和栈膨胀；需控制小数组阈值、避免共享切片竞态、正确写回结果。
Go 里用 goroutine 实现并行归并排序，不是简单地把递归函数改成 go mergeSortHelper(...) 就完事——那样大概率跑不起来，或比串行还慢。关键在于：合并阶段不可并行，但「分块排序」和「多路归并」可以并行；而分治过程本身若盲目并发，反而会因调度开销、内存竞争和栈帧膨胀拖垮性能。
为什么不能直接 go mergeSort(nums[left:mid])
递归调用本身有隐式依赖：左半边必须排完，右半边才能开始合并；而合并操作要读写同一块临时缓冲区 temp，若两个 goroutine 同时往 temp 写，结果不可预测。更实际的问题是：
- goroutine 启动成本虽低（2KB 栈），但每层递归都启两个 goroutine，深度
O(log n)时，总 goroutine 数达O(n)，比如n = 1e6时约 200 万个 goroutine，调度器直接卡死 - 未加锁的共享切片（如
nums或temp）被多个 goroutine 并发读写，触发 data race，go run -race一跑就报错 - 小数组（如长度
真正可行的并行策略：分块 + goroutine + heap 归并
生产级做法是放弃“递归并发”，改用「预分块 → 并发排序子块 → 多路归并」三段式。核心是让并发只发生在彼此隔离的子任务上：
- 先将原数组切成
numWorkers个 chunk（例如按 CPU 核心数，runtime.NumCPU()） - 每个 chunk 启一个 goroutine 调用串行
mergeSort（内部带小数组优化和复用temp） - 所有 chunk 排好后，用最小堆（
heap.Interface）做 k-way merge，这个阶段必须串行，但数据局部性好、缓存友好
示例关键逻辑：
立即学习“go语言免费学习笔记（深入）”；
// sortedChunks 是 []([]int)，每个子切片已有序
h := &minHeap{}
heap.Init(h)
for i, chunk := range sortedChunks {
if len(chunk) > 0 {
heap.Push(h, &item{value: chunk[0], chunkIdx: i, elemIdx: 0})
}
}
for h.Len() > 0 {
it := heap.Pop(h).(*item)
result = append(result, it.value)
if it.elemIdx+1 < len(sortedChunks[it.chunkIdx]) {
heap.Push(h, &item{
value: sortedChunks[it.chunkIdx][it.elemIdx+1],
chunkIdx: it.chunkIdx,
elemIdx: it.elemIdx + 1,
})
}
}
goroutine 数量和 sync.Pool 的取舍
并发度不是越多越好。实测表明，在 16 核机器上，设 numWorkers = runtime.NumCPU() 通常吞吐最高；超过后 GC 压力陡增，pprof 会显示 runtime.mallocgc 占比飙升。至于 sync.Pool：
- 仅当单次排序产生 >10k 个
*item（即 chunk 数多、且每个 chunk 很短）时才值得引入 - 否则池化带来的
mutex争用和对象生命周期管理开销，反而比直接new(item)慢 -
item结构体本身应保持小（三个字段，int类型），避免逃逸到堆
容易被忽略的底层细节
很多人卡在最后一步：归并结果写回原切片时 panic。原因常是 copy(nums, result) 长度不匹配——result 是新分配的切片，而 nums 是输入参数，可能被底层数组复用。正确做法是确保输入切片可写，或显式要求调用方传入容量足够的 nums。另一个坑是：没控制小数组阈值，对长度为 1 的 chunk 还启 goroutine，纯属浪费。这些细节不处理，代码在百万级数据下必崩。
