绝大多数业务排序应使用sort.Slice，它通过闭包灵活支持多字段、动态条件排序；仅当需固化排序逻辑到类型或封装自定义集合时才实现sort.Interface。
直接用 sort.Slice 就够了，95% 的场景不需要手写 sort.Interface；只有当排序逻辑要固化进类型、或封装自定义集合（如优先队列）时，才值得实现接口。
什么时候该用 sort.Slice 而不是 sort.Interface
绝大多数业务排序——比如按用户状态+创建时间+姓名排序、按字符串长度降序、按结构体嵌套字段动态比较——都该用 sort.Slice。它接受任意切片和一个 func(i, j int) bool 闭包，写在哪、改哪、复用哪都很自由。
- 闭包能捕获外部变量，比如按当前用户权限决定排序字段，
sort.Interface做不到这点 - 同一结构体在不同 handler 里要用不同规则？写两个闭包就行，不用改结构体定义
- 性能几乎无差别：
sort.Slice底层就是转成临时sort.Interface实例调用的 - 容易踩坑：在循环里写
for _, v := range items { sort.Slice(..., func() { v.Field }) }，v是复用的，得用索引或显式拷贝
sort.Interface 的三个方法怎么写才不出 panic
真要实现接口时，Less 方法里最常出 panic: index out of range，但原因往往不是下标越界——sort 包调用 Less 前已确保 i 和 j 在 [0, Len()) 内。
- 真正原因是
s本身是nil切片，或者Len()返回了错误长度（比如忘了对指针解引用：*s而不是s） -
Swap里别用值拷贝：a, b := s[i], s[j]; s[i] = b; s[j] = a看似没问题，但若s是大结构体切片，会触发两次复制；应直接交换地址：s[i], s[j] = s[j], s[i] -
Less中访问字段前，先确认字段可导出（首字母大写），否则闭包外无法读取
多字段排序的写法和常见陷阱
复合排序不能靠“链式调用”，必须在一个 func(i, j int) bool 里手动写优先级逻辑。用短路表达式比嵌套 if 更安全、更易读。
立即学习“go语言免费学习笔记（深入）”；
sort.Slice(orders, func(i, j int) bool {
a, b := orders[i], orders[j]
if a.Status != b.Status {
return a.Status < b.Status // 状态升序
}
if !a.CreatedAt.Equal(b.CreatedAt) {
return a.CreatedAt.Before(b.CreatedAt) // 时间升序
}
return strings.ToLower(a.Name) < strings.ToLower(b.Name) // 名字忽略大小写升序
})
- 空值处理必须显式：比如
*string字段为nil，直接*a.Name会 panic；得先判空：a.Name != nil && b.Name != nil && *a.Name - 零值字段（如
0、""）是否排前面/后面，没有默认行为，全看业务需求，不写清楚就会埋雷 - 如果字段是时间、浮点数等，注意精度问题：
time.Time比较用.Before()或.Equal()，别用==
泛型排序函数不是银弹，别强行套用
泛型不能替代 sort.Slice 的灵活性。想写个通用 Sort[T any] 函数？T 加 comparable 约束没用——它只保证能用 ==，不保证能排序（比如含切片的 struct 就不可比）；加 constraints.Ordered 又只覆盖基础类型，不支持结构体。
- 真正通用的做法是封装
SortBy[T any](s []T, less func(i, j int) bool)，内部调用sort.Slice，既保留泛型类型检查，又不牺牲比较逻辑自由度 - 如果排序规则固定且高频复用（比如所有日志条目都按时间倒序），才考虑用泛型 + 接口组合，例如
type LogSlice []Log实现sort.Interface，再配一个func (l LogSlice) SortByTimeDesc()方法 - 别为了用泛型而反射、而 interface{}，Go 的类型系统优势恰恰在于编译期确定性
最复杂的点往往不在排序逻辑本身，而在空值、零值、指针解引用、字段可见性这些细节上；闭包写法看着随意，但每处 [] 访问、每次 . 取字段，都要心里有数它会不会 panic。
