sort.Slice不能直接用于泛型切片，因为它要求[]interface{}或具体类型切片且比较函数签名固定为func(i,j int)bool，不感知元素类型，也无法编译期校验类型是否支持比较；泛型排序必须通过约束确保类型可比较，否则编译失败。
为什么 sort.Slice 不能直接用于泛型切片
因为 sort.Slice 要求传入 []interface{} 或具体类型切片，且比较函数签名固定为 func(i, j int) bool，它不感知元素类型，也没法在编译期校验类型是否支持比较。泛型排序必须靠约束（constraint）确保类型能比较，否则连编译都过不了。
常见错误现象：invalid operation: cannot compare a > b (operator > not defined on type T) —— 这说明你没给泛型参数加可比较约束。
- 数值类型如
int、float64支持==和，但泛型中默认不认为它们“可比较”，需显式用 <code>constraints.Ordered -
constraints.Ordered是标准库golang.org/x/exp/constraints提供的预定义约束（Go 1.22+ 已移至constraints包，但实际仍推荐用comparable+ 手动判断或第三方库） - 更稳妥的做法是限定为数值类型：用
~int | ~int32 | ~int64 | ~float64 | ~float32等类型集，避免误传 struct 或指针
怎么写一个真正通用的数值比较器函数
别封装成闭包或 interface{}，直接用泛型函数 + 类型约束，让编译器帮你检查合法性。
func Less[T ~int | ~int32 | ~int64 | ~float32 | ~float64](a, b T) bool {
return a < b
}
这个 Less 函数能被任何数值类型调用，且不会接受 string 或 []byte —— 编译时就报错。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
~int表示“底层类型为 int 的任意命名类型”，比如type MyInt int也能用 - 如果需要支持 uint 类型，得额外加上
~uint | ~uint32 | ~uint64，注意uint和int之间不能混用比较 - 不要用
comparable当约束来写数值比较器——它只保证==，不保证存在
如何把比较器集成进泛型排序函数
Go 标准库没有泛型版 sort.Sort，所以得自己实现简易快排或复用 sort.Slice + 类型断言——但后者失去泛型安全。推荐封装一个带比较器的排序：
func SortSlice[T ~int | ~int32 | ~int64 | ~float32 | ~float64](s []T, less func(T, T) bool) {
sort.Slice(s, func(i, j int) bool {
return less(s[i], s[j])
})
}
调用时直接传入上面定义的 Less 函数：
nums := []int{3, 1, 4}
SortSlice(nums, Less[int])
- 注意：不能写
SortSlice(nums, Less)，Go 不支持泛型函数类型自动推导为参数，必须显式实例化 - 如果想省掉类型参数，可以把
Less定义为泛型方法或使用函数别名，但会增加理解成本 - 性能上无额外开销——
less是内联函数调用，编译后和手写s[i] 几乎等价
容易忽略的边界：浮点数 NaN 和精度问题
用 Less[float64] 排序含 NaN 的切片时，NaN 和 <code>x 全为 <code>false，导致排序结果不稳定甚至 panic（取决于 sort 实现）。这不是泛型的问题，而是浮点语义本身决定的。
- 如果你的数据可能含
NaN，必须前置清理：math.IsNaN检查并单独处理 -
float32和float64的精度差异会影响相等性判断，但比较不受影响；不过若依赖排序后去重，就得小心浮点误差 - 整数类型不存在这个问题，但要注意溢出——比如
int8(127) + 1在比较前就可能越界，这属于业务逻辑层该管的事
泛型解决的是类型安全和复用，不是数值语义的兜底。该检查 NaN 的地方，一行 if math.IsNaN(x) { ... } 不能少。
