Go标准库sort包不固定使用快速排序，而是根据长度、有序度、递归深度等动态选择插入排序、pdqsort或堆排序；sort.Ints不稳定，结构体排序需用sort.SliceStable或包装后调.Stable()。
Go 标准库 sort 包根本不用“快速排序”这个说法
你调用 sort.Ints 或 sort.Sort 时，底层确实可能走 quickSort，但它只是动态策略中的一环，不是固定入口。标准库从不暴露“选快排”这个控制权——你无法指定、也无法禁用它。真正起作用的是输入长度、数据分布、递归深度等运行时特征。
常见错误现象：sort.Ints([]int{1,2,3,...,10000})（已升序）跑得飞快，但自己手写的纯快排可能直接 O(n²)；误以为“标准库用了更高级的快排”，其实是它早跳过了快排路径。
- 长度 ≤12：直接进
insertionSort，不碰 pivot - 长度 ≤1000 且近似有序：
pdqsort会触发partialInsertionSort快速收尾 - 递归太深（比如反复切出极不平衡子数组）：自动 fallback 到
heapSort防栈溢出
sort.Ints 和手写快排在稳定性上天然不同
sort.Ints 不稳定，这不是 bug，是设计使然：它混合了快排、堆排、希尔排，三者全都不保序。而你自己实现的快排，哪怕加了三数取中、尾递归优化，只要没显式处理相等元素的下标关系，就一样不稳定。
使用场景：结构体切片按 Age 排序时，两个 Age==18 的人顺序变了——这不是数据错乱，是你该换 sort.SliceStable 或包装 sort.IntSlice 后调 .Stable()。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
sort.Stable对基础类型切片不直接支持，必须先转成sort.IntSlice再调.Stable() - 手写快排若想稳定，得改成交换逻辑+额外记录原始索引，代价远超换用标准库
- 性能影响：稳定版常数更大，局部性略差，但时间复杂度仍是 O(n log n)
自定义排序别硬套快排逻辑，优先用 sort.Slice
你写 sort.Slice(students, func(i, j int) bool { return students[i].Score ，底层根本不会调快排函数——它走的是和 <code>sort.Sort 类似的多算法混合路径，只是省去了接口实现的样板代码。
容易踩的坑：用 sort.Slice 时传入闭包捕获了外部变量，结果排序中途变量被改，Less 行为突变；或者闭包里做了耗时 IO/网络调用，拖慢整个排序。
-
sort.SliceStable才保序，sort.Slice不保 - 闭包中只做纯比较，避免副作用
- 如果比较逻辑复杂（比如要查 map、调函数），提前算好 key 放到临时切片里再排，别在
Less里实时算
想看快排到底有没有执行？得看源码里的 doPivot 和 limit
标准库快排路径里最关键的两个控制点是 doPivot（三数取中）和 limit（递归深度阈值）。前者确保 pivot 不是首/尾极端值，后者防退化。但这些全是内部逻辑，对外不可见。
实际影响：同一份数据，在 Go 1.21 和 Go 1.24 上，sort.Ints 可能走不同路径——因为 pdqsort 的启发式判断逻辑升级了。你不能依赖“这次走了快排，下次一定也走”。
- 测试不可重现？别在快排里用
rand，标准库所有 pivot 选择都是确定性的 - 想强制走某算法？做不到。标准库没留钩子，也不鼓励你绕过它自己实现
- 真要分析性能瓶颈，用
go tool pprof看runtime.mcall和sort.quickSort占比，而不是猜它用了啥
