Go中实现泛型快排需用comparable约束类型，原地分区并检查low
Go 语言里怎么写一个可用的快速排序函数
直接上手写 QuickSort，别套递归模板。Go 没有内置的原地快排，sort.Slice 虽好但不透明，自己实现才能控制分区逻辑、避免 panic、适配自定义类型。
核心是「选基准 + 分区 + 递归」三步，但 Go 切片传参是引用底层数组的，所以必须原地操作，不能靠返回新切片——否则性能垮掉，还容易误以为修改了原数据。
-
partition函数必须返回基准最终位置（不是中间索引），否则左右子区间划分会错位 - 递归边界要检查
low ，不是 <code>low ，否则单元素时无限递归 - 基准选
arr[low]最简单，但遇到已排序数组会退化成 O(n²)；生产环境建议用arr[(low+high)/2]或随机索引
如何让快排支持任意可比较类型
Go 泛型从 1.18 开始可用，不用再靠 interface{} + reflect 硬扛。直接用类型参数约束可比较性，编译期就能报错，运行时零开销。
关键不是“能不能泛型”，而是泛型声明里要不要加 comparable：如果只做排序，必须加；如果后续要支持自定义比较函数（比如按结构体字段），就得换成 func(T, T) bool 参数。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 泛型签名写成
func QuickSort[T comparable](arr []T)，比any安全得多 - 分区过程里所有比较（
arr[i] ）都依赖 <code>T实现了==和？不，Go 不要求实现 <code>，所以这里实际只能用于基础类型（<code>int,string,float64）或自定义类型显式支持比较的场景 - 真要支持结构体字段排序，得把
pivot和比较逻辑抽成函数参数，例如less func(T, T) bool
分区函数常见的 panic 和越界问题
最常崩在 index out of range，尤其当 low == high 或切片为空时没提前 return。Go 不会自动跳过空区间，你写的每一步都要自己兜底。
典型错误是 while 循环里先 i++ 再判断 i ，结果 <code>i 已经越界才检查——应该先判界再移动指针。
- 初始化
i := low - 1和j := high + 1，避免首尾漏判 - 内层循环必须用
for+ 显式break，不能用if+continue混淆流程 - 交换前务必确认
i ，否则可能把 pivot 自己跟自己 swap，逻辑错乱 - 示例片段：
for i < j { for i++; i < j && arr[i] < pivot; i++ {} for j--; i < j && arr[j] > pivot; j-- {} if i < j { arr[i], arr[j] = arr[j], arr[i] } }
为什么你的快排比 sort.Ints 慢 3 倍
不是算法问题，是 Go 运行时对内置 sort 包做了深度优化：小数组用插入排序、中等用快排、大数组混入堆排序防最坏，还有内联和内存预取。你自己写的纯快排没有这些，还多了泛型类型擦除开销（即使没用到）。
真实项目里，除非要定制分区策略（比如按绝对值排）、或处理特殊内存布局（如 mmap 文件），否则别替掉 sort.Slice。自己实现的价值在于理解过程，不是替代标准库。
- 微基准测试用
go test -bench，但注意别测空切片或长度为 1 的情况——这些是sort的快路径，你的代码可能根本没走主逻辑 - 开启
-gcflags="-m"看泛型是否被内联，没内联的话每次调用都有函数调用开销 - 真正影响性能的是缓存局部性：你的分区是否尽量顺序读写？有没有频繁跨 Cache Line 访存？这点比选 pivot 重要得多
快排的 pivot 选择、尾递归优化、三数取中这些细节，在 Go 里不如先确保切片没被意外复制、分区循环没多一次边界检查来得实在。
