sort.Slice 是更安全、更快且防退化的排序方案，但需严格满足三个硬约束：data 不能为 nil、less 函数必须满足严格弱序、nil 指针字段须显式判空；手写快排仅适用于算法题或禁用标准库场景。
别花五分钟学手写快排——sort.Slice 一行就能干完，且更安全、更快、自带防退化；你真正该花时间搞懂的，是它三个容易 panic 的硬约束和怎么绕过它们。
sort.Slice 为什么比手写快排更推荐
标准库 sort.Slice 不是“够用”，而是对绝大多数业务场景已是最优解：它底层复用 sort.quickSort 的优化实现（随机 pivot + 小数组切插入排序 + 递归深度保护），性能不输手写，还省去边界判断、空切片 panic、底层数组逃逸等一整套坑。
常见错误现象：panic: runtime error: index out of range [0] with length 0 —— 手写版本里 arr[len(arr)-1] 在空切片上直接崩；而 sort.Slice 内部已做 len(data) == 0 短路，你只要传进去就稳。
使用场景：
立即学习“go语言免费学习笔记（深入）”；
- 按结构体字段排序（如
Price、Name） - 多条件组合（先按状态再按时间）
- nil 安全字段比较（比如
*string字段要显式判空）
sort.Slice 必须满足的三个硬约束
它不报错时很顺，一报错就是 runtime panic，原因几乎都卡在这三条：
-
data切片不能为nil：必须提前检查，if data == nil || len(data) == 0 { return } - 比较函数
less(i, j int) bool必须满足严格弱序：对任意i，less(i, i)必须返回false；写成return a[i].X 就会未定义行为 - 字段含
nil指针或空字符串时，less里必须显式处理，否则访问 panic；例如if a[i].Name == nil { return false }（把nil当最大值）
非要手写 quicksort？只保留这个最小可靠骨架
仅限算法题、教学演示、或嵌入式禁用标准库。以下版本已验证：空切片安全、pivot 归位正确、不新建底层数组、终止条件鲁棒。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
关键点：
- 函数签名带
low, high int，避免依赖len(arr)计算边界 - 分区用 Lomuto 方式（易懂），pivot 固定选
arr[high]，交换后返回其最终索引 - 递归终止条件是
low >= high，不是len(arr) （后者在子切片中完全失效）
示例：
func quickSort(arr []int, low, high int) {
if low >= high {
return
}
p := partition(arr, low, high)
quickSort(arr, low, p-1)
quickSort(arr, p+1, high)
}
<p>func partition(arr []int, low, high int) int {
pivot := arr[high]
i := low - 1
for j := low; j < high; j++ {
if arr[j] <= pivot {
i++
arr[i], arr[j] = arr[j], arr[i]
}
}
arr[i+1], arr[high] = arr[high], arr[i+1]
return i + 1
}append 拼接左右子数组永远排不对原切片
这是 Go 新手最常踩的语义坑：你以为 append(left, pivot, right...) 排好了，其实只是建了个新切片，原 arr 完全没变。
后果：
- 原切片未被修改，后续
sort.Search查不到结果 - 每次递归都分配新底层数组，空间复杂度从
O(1)暴涨到O(n²) - GC 压力陡增，尤其在高频调用场景下明显
正确做法：所有操作必须基于原切片底层数组，只用 arr[i], arr[j] = arr[j], arr[i] 原地交换；若需不修改原数据，应显式 copy 一份再传入。
真正难的不是写对 partition，而是意识到：你写的每一行快排代码，都在和 Go 切片的引用语义、底层数组共享、边界计算做对抗。标准库已经替你扛下了这些，别为了“练手”把自己绕进 panic 循环里。
