Go中递归归并排序易栈溢出，因默认goroutine栈仅2KB，千万级数据递归深度约24层，若未设终止阈值或频繁分配切片，会快速耗尽栈空间并触发panic。
为什么递归实现归并排序在 Go 里容易栈溢出
Go 的默认 goroutine 栈初始只有 2KB，而深度递归（比如对千万级切片做 mergeSort）会快速耗尽栈空间，触发 runtime: goroutine stack exceeds 1000000000-byte limit 或直接 panic。这不是算法错，是调用栈没控制好——每次递归都复制子切片头（哪怕只是指针），且深度达 O(log n)，当 n = 1e7 时，递归深度约 24 层，看似不高，但若每层还做切片分配或误传大底层数组，风险陡增。
- 避免用
nums[:mid]和nums[mid:]直接递归传参：这不会复制数据，但若原切片底层数组极大，且递归中又频繁创建新切片（如合并时用make([]int, len(left)+len(right))），会拖慢 GC 并隐式延长栈帧生命周期 - 真正危险的是「未设递归终止阈值」：比如对长度为 10 的子数组仍继续拆成 5+5 → 2+3 → 1+1+1+2… 实际上，
len(nums) 时直接用插入排序更稳、更快，也省递归 - 别依赖
runtime.GOMAXPROCS来“解决”栈溢出——它管的是并发，不是单 goroutine 栈大小
怎么写一个生产可用的 mergeSort 函数
核心是：复用临时空间 + 控制递归深度 + 原地合并逻辑清晰。不要每次合并都 make 新切片，而是预分配一块和原数组等长的 temp，所有合并操作都在它上面读写，最后拷回原数组。
- 入口函数只做一次
temp := make([]int, len(nums))，然后调用带temp参数的内部递归函数：mergeSortHelper(nums, temp, 0, len(nums)-1) - 递归边界设为
left >= right（单元素或空区间直接返回），同时加一层小数组优化：if right-left - 合并时严格按索引操作，避免切片越界：用
mid := left + (right-left)/2，而非(left+right)/2（防整数溢出）；左右子区间为[left, mid]和[mid+1, right]
func mergeSort(nums []int) {
if len(nums) <= 1 {
return
}
temp := make([]int, len(nums))
mergeSortHelper(nums, temp, 0, len(nums)-1)
}
func mergeSortHelper(nums, temp []int, left, right int) {
if left >= right {
return
}
if right-left < 16 {
insertionSort(nums[left:right+1])
return
}
mid := left + (right-left)/2
mergeSortHelper(nums, temp, left, mid)
mergeSortHelper(nums, temp, mid+1, right)
merge(nums, temp, left, mid, right)
}
merge 函数里最容易写错的三处
合并本身逻辑简单，但 Go 切片语义和边界处理极易出错，尤其在多层递归下，错一点就导致数据错位或 panic。
- 别用
copy(temp[left:right+1], ...)直接覆盖——temp是整块预分配的，你得明确知道当前合并段在temp中的起始位置，应写成copy(temp[left:right+1], merged)，其中merged是本次合并结果切片 - 左右指针初始化错误：左子数组范围是
[left, mid]，所以i := left；右子数组是[mid+1, right]，所以j := mid + 1；不是j := mid - 合并后忘记把
temp[left:right+1]拷回nums[left:right+1]——这是最常漏的一步，结果跑完函数，nums还是老样子
什么时候该放弃归并排序，改用 sort.Ints
除非你在写算法题、教学代码，或有强稳定性/可预测性要求（比如实时系统里不能接受快排最坏 O(n²)），否则真没必要手写 mergeSort。Go 标准库的 sort.Ints 是优化过的混合排序（introsort）：小数组用插入，中等用快排，退化时切堆排，平均 O(n log n)，稳定且经过多年压测。
立即学习“go语言免费学习笔记（深入）”；
- 性能上，
sort.Ints比手写归并快 20%~40%，尤其在缓存友好性（局部性）和内联优化上优势明显 - 内存上，它不额外申请 O(n) 空间，而你的归并排序即使优化了
temp复用，仍需一块等长缓冲区 - 唯一例外：你需要稳定排序 + 自定义比较逻辑 + 不能修改原切片内容（比如要返回新切片）。这时才值得封装一层
StableSort，且务必加上小数组优化和栈深度防护
手写归并排序最易被忽略的点，其实是「没想清楚到底要排序副本还是原地」——如果目标是返回新切片，就别在 mergeSort 内部反复操作 nums，而应统一走 result := append([]int(nil), nums...) 开头；这个细节一错，后面所有优化都白搭。
