手写归并排序在Go中仅适用于稳定排序+自定义合并或算法教学场景；常见错误包括中点计算错误（应为left+(right-left)/2）、终止条件误用len(nums)、子区间定义不一致、临时空间复用错位及剩余段拷贝越界。
手写归并排序在 Go 里不是不能做，但绝大多数业务场景下真没必要——sort.Ints、sort.Strings 或 sort.Slice 更快、更稳、更少出错。只有当你明确需要稳定排序 + 自定义合并逻辑（比如按时间戳分段归并日志），或正在刷算法题/教学演示时，才值得碰手写版。
mergeSort 递归入口最常犯的索引错误
错误写法是用 len(nums) 算中点，而不是用当前子区间的长度。比如传入 mergeSort(nums, 0, len(nums)-1) 后，在函数体内写 mid := len(nums) / 2，这会导致每次递归都切同一个位置，陷入无限调用。
- 正确做法：中点必须基于当前边界计算 ——
mid := left + (right-left)/2，既防整数溢出，又保证每次拆分落在[left, right]范围内 - 递归终止条件必须是
left >= right，而不是len(nums) ；后者在递归中完全失效，因为 <code>nums始终是原始切片 - 别对空区间（
left > right）做任何操作，Go 切片允许nums[left:right]返回空切片，但nums[right:left]会 panic
merge 函数里最容易写错的三处
合并本身逻辑简单，但 Go 切片语义和边界处理极易出错，尤其在多层递归下，错一点就导致数据错位或 panic。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 左右子区间定义不一致：应为
[left, mid]和[mid+1, right]，不是[left, mid-1]或[mid, right]；否则漏元素或越界 - 临时空间复用没对齐：如果预分配了
temp := make([]int, len(nums))，合并时必须只写入temp[0:k]，再用copy(nums[left:right+1], temp[:k])写回 —— 不能直接nums = append(...)，那会丢失原底层数组引用 - 剩余段拷贝遗漏或越界：两个
for循环分别处理左/右子数组剩余部分，起始索引和结束条件必须严格对应原始nums的i、j位置，不能凭感觉写copy(temp[k:], nums[i:])
为什么递归归并排序在 Go 里容易栈溢出
不是算法问题，是 Go 运行时限制和实现细节共同作用的结果：默认 goroutine 栈仅 2KB，而千万级数据递归深度约 24 层，每层若还频繁分配切片头或误传大底层数组，栈帧迅速膨胀。
立即学习“go语言免费学习笔记（深入）”；
- 真正危险的是没设小数组优化阈值：当
right - left 时，直接用插入排序比继续递归更快，也避免无谓的栈开销 - 禁止用
nums[:mid]和nums[mid:]作为参数递归传入 —— 虽不复制数据，但若原切片底层数组极大，GC 会延长整个栈帧生命周期 - 别指望
runtime.GOMAXPROCS能缓解：它控制并发 goroutine 数量，跟单个 goroutine 的栈大小无关；真要扩栈得用runtime/debug.SetMaxStack，但这是掩耳盗铃，治标不治本
生产环境里，哪怕你写了“完美”的归并排序，只要没做小数组切换、没复用临时空间、没校验索引边界，它就只是个看起来能跑的 demo。真正的难点不在“怎么合并”，而在“怎么让递归不把自己搞崩”。
