slices.sortfunc 不能直接用 strings.compare 排序字符串切片，因类型推导失败；需内联函数或显式类型实例化，且多字段排序须手动实现链式逻辑。
slices.SortFunc 是 Go 1.21 引入的、用于对任意类型切片排序的标准库函数，它不修改原切片类型约束，也不依赖 sort.Interface，而是直接接受一个比较函数。但要注意：它只适用于支持泛型的切片（即 []T），且比较函数必须严格符合 func(T, T) int 签名。
为什么 slices.SortFunc 不能直接排序字符串切片？
常见错误是传入 strings.Compare —— 它签名是 func(string, string) int，看似匹配，但 slices.SortFunc 要求类型参数 T 在调用时能被推导为具体类型，而 strings.Compare 是独立函数，不是闭包或泛型适配器，Go 类型推导常失败，导致编译报错：
cannot use strings.Compare (value of type func(string, string) int) as type func(string, string) int in argument to slices.SortFunc
这不是逻辑错误，是类型系统对函数字面量和具名函数的实例化差异所致。
正确做法是显式提供内联比较逻辑：
- 对
[]string：用func(a, b string) int { return strings.Compare(a, b) } - 或更轻量：直接用
strings.Compare的返回值逻辑，如if a b { return 1 }; return 0 - 避免依赖
strings.Compare本身作为参数传入
slices.SortFunc 和 sort.Slice 的关键区别在哪？
两者都支持自定义比较，但底层机制和适用场景不同：
-
slices.SortFunc要求切片元素类型可比较（comparable或满足泛型约束），且比较函数必须是func(T, T) int；它内部使用优化过的 pdqsort，对小切片自动切分，性能略优于sort.Slice默认实现 -
sort.Slice接受[]any（实际是interface{}切片）和闭包func(i, j int) bool，无需泛型约束，适合字段访问、类型断言等复杂逻辑，但每次比较都要索引+取值，有额外开销 - 若你已用泛型封装了业务类型（如
type User struct{...}），优先选slices.SortFunc；若要按嵌套字段（如u.Address.City）动态排序，sort.Slice更灵活
如何安全地对结构体切片按多个字段排序？
slices.SortFunc 本身不支持“链式比较”，需手动实现多级逻辑。例如按 Name 升序、Age 降序：
persons := []Person{{"Alice", 30}, {"Bob", 25}, {"Alice", 22}}
slices.SortFunc(persons, func(a, b Person) int {
if a.Name != b.Name {
return strings.Compare(a.Name, b.Name)
}
if a.Age != b.Age {
return b.Age - a.Age // 降序：大值在前
}
return 0
})
注意点：
- 字段比较顺序决定主次优先级，务必先判主导字段
- 数值降序别写
a.Age - b.Age再取负，易整数溢出；用b.Age - a.Age更安全 - 字符串比较统一用
strings.Compare，避免==+混用导致逻辑断裂 - 如果结构体含指针或接口字段，需先判空再比较，否则 panic
真正容易被忽略的是：当你把比较函数提取为变量（如 cmp := func(a, b T) int {...}）再传给 slices.SortFunc 时，Go 可能无法推导 T，必须显式实例化类型参数，比如 slices.SortFunc[Person](persons, cmp)。泛型推导在函数变量场景比字面量更脆弱。
