sort.Slice 是最常用且安全的自定义排序方式，Go 1.8 引入，无需实现 sort.Interface，直接传切片和比较函数；注意仅支持切片、比较函数返回 bool、不可修改原数据。
sort.Slice 是最常用也最安全的自定义排序方式
Go 1.8 引入的 sort.Slice 是当前推荐的自定义排序入口，它不要求类型实现 sort.Interface，直接传入切片和比较函数即可，避免了类型定义冗余和潜在的 panic。
常见错误是误用 sort.Sort 配合匿名结构体或临时类型，结果因未实现全部三个方法（Len、Less、Swap）而编译失败或运行时 panic。
- 只对切片排序 ——
sort.Slice不支持数组或 map - 比较函数必须返回
bool，且语义为“前一个是否应排在后一个之前”（即升序逻辑） - 切片元素可寻址，但比较函数里不能修改原切片内容（否则行为未定义）
- 示例：按字符串长度降序
names := []string{"Alice", "Bob", "Charlie", "Dan"}
sort.Slice(names, func(i, j int) bool {
return len(names[i]) > len(names[j]) // 注意是 >
})
// 结果: ["Charlie", "Alice", "Bob", "Dan"]
实现 sort.Interface 适合高频复用或复杂排序逻辑
当同一类型需要多种排序策略（如按创建时间、按状态再按 ID），或排序逻辑被多处调用，封装成类型并实现 sort.Interface 更清晰。但必须确保三个方法都正确定义，否则 sort.Sort 会静默出错或 panic。
容易忽略的是 Swap 方法——很多人只写 Len 和 Less，漏掉 Swap 导致运行时报 panic: reflect.Value.Interface: cannot return value obtained from unexported field or method（尤其在使用 struct 字段时）。
立即学习“go语言免费学习笔记（深入）”；
-
Len()返回int，不是int64或其他类型 -
Less(i, j int)的索引必须在[0, Len())范围内，函数内不负责边界检查 -
Swap(i, j int)必须真正交换元素，不能空实现 - 如果结构体字段非导出（小写开头），
Swap中需通过 setter 或整体赋值，不能直接访问字段
sort.SliceStable 和 sort.Stable 的稳定性差异很关键
默认的 sort.Slice 和 sort.Sort 不保证相等元素的相对顺序（不稳定排序）。若业务要求“相同分数的学生按报名先后排序”，就必须用稳定版本。
注意：sort.SliceStable 和 sort.Stable 性能略低（约 10–20%），仅在确实需要稳定性时启用；且 sort.SliceStable 的比较函数签名与 sort.Slice 完全一致，无需改动逻辑。
- 稳定性只对“
Less(i,j)==false && Less(j,i)==false”的元素生效（即视为相等） - 浮点数比较慎用
==判断相等，建议用误差范围 + 稳定排序组合 - 数据库分页场景中，若排序字段有重复值，前端翻页错乱往往源于用了非稳定排序
基础类型排序别绕弯，优先用专用函数
对 []int、[]string、[]float64 这类基础切片，直接用 sort.Ints、sort.Strings、sort.Float64s，比 sort.Slice 快 15–30%，且代码更直白。
反模式是统一用 sort.Slice 处理所有切片，既损失性能，又掩盖了类型意图。例如 sort.Slice(nums, func(i,j int) bool { return nums[i] 完全等价于 sort.Ints(nums)，但前者多一层函数调用和闭包开销。
-
sort.Ints等函数内部使用优化过的插入+快排混合算法，对小切片特别友好 - 它们不接受自定义比较逻辑，所以升序/降序必须手动反转切片（
sort.Sort(sort.Reverse(sort.IntSlice(nums)))）或用sort.Slice - 注意
sort.IntSlice是类型别名，不是函数；sort.Reverse包装的是sort.Interface实现，不是切片本身
真正麻烦的从来不是“怎么写排序”，而是“什么时候该用稳定排序”“相等性定义是否和业务一致”“比较函数里有没有隐式 panic（比如 nil 指针解引用）”。这些细节不写测试很难暴露。
