Go 中 mergeSort 易栈溢出，因默认 goroutine 栈仅 2KB，递归截取切片仍共享底层数组但持续压栈帧，且 merge 内动态分配加剧压力；应预分配临时缓冲区并复用，避免递归中新建切片或调用 make/append。
mergeSort 在 Go 里直接照搬递归写法很容易 panic: runtime error: stack overflow，尤其当输入切片长度 ≥ 1e5 时。根本原因不是算法错，而是默认 goroutine 栈仅 2KB，而 naïve 递归每层都新建切片头、分配临时空间，调用帧叠加后迅速溢出。
为什么 mergeSort(nums[:mid]) 会爆栈？
常见错误是把切片截取当作“传子数组”，误以为 nums[:mid] 和 nums[mid:] 是独立内存——其实它们仍共享底层数组，但每次递归调用都会压一个新栈帧，且 merge 函数若再内部 make([]int, ...)，堆+栈双重压力就来了。
- 递归深度约 log₂(n)，n=1e6 时约 20 层，看似安全，但调试模式、GC 延迟、或带 panic 捕获的 wrapper 会让实际栈消耗翻倍
-
len(nums)在递归中始终是原始长度，若用它算mid（比如mid := len(nums)/2），会导致mergeSort(nums[:mid])实际总在处理同一段索引，无限递归 - 更隐蔽的问题：
append在merge中动态扩容，可能触发多次底层数组复制，放大内存抖动
怎么写一个不爆栈的 merge 函数？
核心是「复用 + 预分配」：合并逻辑不新建切片，只操作原数组区间；临时缓冲区在顶层一次性分配，传入各层 merge 复用。
- 函数签名必须是
func merge(nums []int, temp []int, left, mid, right int)，其中temp是预分配好的缓冲区（长度至少right-left+1） - 合并时只读
nums[left:right+1]，写入temp[0:k]，最后用copy(nums[left:right+1], temp[:k])一次性刷回 - 避免在
merge内部调用make、append或任何可能分配堆内存的操作
func merge(nums []int, temp []int, left, mid, right int) {
i, j, k := left, mid+1, 0
for i <= mid && j <= right {
if nums[i] <= nums[j] {
temp[k] = nums[i]
i++
} else {
temp[k] = nums[j]
j++
}
k++
}
for i <= mid {
temp[k], i, k = nums[i], i+1, k+1
}
for j <= right {
temp[k], j, k = nums[j], j+1, k+1
}
copy(nums[left:right+1], temp[:k])
}
递归版怎么加安全兜底？
不彻底弃用递归的话，至少要设两个阈值：一是长度阈值，小数组切回插入排序；二是深度阈值，防意外死递归。
- 当
len(nums) 时，直接用插入排序，省去递归开销 - 在递归函数签名中加一个
depth int参数，顶层传 0，每次递归 +1；若depth > 64就 panic 或 fallback 到sort.Ints(nums) - 计算
mid必须基于当前区间：用mid := left + (right-left)/2，而不是len(nums)/2 - 递归调用应为
mergeSort(nums, left, mid, temp, depth+1)和mergeSort(nums, mid+1, right, temp, depth+1)
业务代码里真需要手写 mergeSort 吗？
绝大多数情况不需要。Go 标准库的 sort.Ints 和 sort.Slice 已针对不同规模数据自动切换算法：小数组插排、中等规模快排、大数组堆排+平衡采样，实测 n=1e6 时比朴素归并快 2–3 倍，且无栈风险。
立即学习“go语言免费学习笔记（深入）”；
- 需要稳定排序 + 自定义比较？用
sort.SliceStable(data, func(i, j int) bool { ... }) - 只是排
[]int？一行sort.Ints(nums)足够 - 只有在算法题、教学、或必须控制合并过程（如外部归并、流式合并）时，才值得投入精力写健壮的归并实现
真正容易被忽略的是：栈溢出往往不报具体行号，只显示 fatal error: stack overflow，这时候得立刻检查 mid 计算逻辑和 temp 是否重复分配——而不是怀疑数据本身有问题。
