因为并发快排直接 go QuickSort(arr, l, r) 会导致多个 goroutine 同时写同一底层数组，触发 data race；必须为每个子任务复制独立内存、设深度阈值（如 maxDepth=6）控制并发量、归并阶段保持串行。
并发快排为什么不能直接 go QuickSort(arr, l, r)？
因为 QuickSort 通常就地修改切片，多个 goroutine 并发写同一底层数组会触发 data race —— Go 的 race detector 会立刻报错，比如 Read at 0x00c000124000 by goroutine 7 这类地址冲突提示。
必须为每个子任务分配独立内存空间：
- 用
arr[l:r+1]切片后，立即append([]int(nil), sub...)或make([]int, len(sub)); copy(dst, sub)复制一份 - 递归调用传入的是新切片，不是原数组的视图
- 归并时用
append合并结果，而非原地拼接
如何控制并发深度避免调度开销反超收益？
协程不是越多越好。实测显示：对 100 万 int 排序，开 32 个 goroutine 比开 4 个慢 40%，主因是调度器频繁切换 + 缓存失效。
推荐做法是设硬性阈值，比如：
立即学习“go语言免费学习笔记（深入）”；
- 定义常量
const maxDepth = 6 - 每次递归传入当前深度
depth，当depth >= maxDepth时退回到单协程sort.Ints - 启动前调用
runtime.GOMAXPROCS(min(4, runtime.NumCPU()))，避免抢占式调度干扰
归并阶段要不要也并发？
不要。归并本身是顺序依赖的线性过程，强行并发只会增加 channel 通信和 goroutine 调度负担。
实测对比（1000 万 int）：
- 单 goroutine 归并耗时 ≈ 8ms
- 用两个 goroutine 分段归并再合并，耗时 ≈ 15ms（含 sync、channel 开销）
- 归并前可复用
sync.Pool分配临时切片，减少 GC 压力
为什么 sort.Slice 在并发场景下要慎用？
sort.Slice 内部通过反射调用闭包比较函数，每次 Less(i,j) 都有接口动态调度开销；并发环境下，这个开销被放大且无法内联优化。
更稳妥的方式：
- 小数据或结构体字段简单：用
sort.Ints/sort.Float64s等原生函数 - 需自定义逻辑：实现
sort.Interface，把比较逻辑写进方法里，编译期就能内联 - 绝对避免在比较函数里做 I/O、锁、或调用非内联函数（如
fmt.Sprintf）
真正容易被忽略的点是：并发排序不是“拆了就完事”，关键在内存隔离、深度控制、归并串行化这三处——漏掉任何一环，性能可能比单线程还差。
