sort.Slice 是 Go 1.8 引入的简化自定义排序方案，只需传切片和比较闭包，底层封装 Len/Less/Swap；常见错误是比较逻辑写反，如该用 a.ID < b.ID 却误写为 a.ID > b.ID。
用 sort.Slice 替代 sort.Interface 实现自定义排序
Go 1.8 引入的 sort.Slice 是最直接的简化方案——不用再写三个方法的结构体，只要传一个切片和一个闭包函数就行。它底层仍调用 sort.Sort，但封装了 Len/Less/Swap 的模板逻辑。
常见错误是把比较逻辑写反（比如该返回 a.ID > b.ID 却写了 ），导致排序结果完全颠倒，且不报错、难排查。
- 只适用于切片（
[]T），不能用于 map 或自定义容器 - 闭包中访问外部变量要小心：若在循环中多次调用
sort.Slice并捕获循环变量，可能所有比较都用到同一个终值（典型闭包陷阱） - 性能上和手写
sort.Interface几乎无差别，因为都是原地排序，但代码量减少 70%+
users := []User{{Name: "Alice", Age: 30}, {Name: "Bob", Age: 25}}
sort.Slice(users, func(i, j int) bool {
return users[i].Age < users[j].Age // 升序：i 在 j 前面时返回 true
})
多字段排序必须链式判断，不能简单用 &&
按「优先级」排序（比如先按 Status 分组，再按 CreatedAt 倒序）时，很多人会写成 a.Status == b.Status && a.CreatedAt.After(b.CreatedAt)，这会导致逻辑错误：当 Status 不同时，整个表达式为 false，排序器误以为 a 应排在 b 后面，实际应先比 Status 再比时间。
正确做法是逐级判断，用 if-return 模式或三元风格嵌套：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 升序字段用
，降序字段用 <code>>，别混用 - 字符串比较建议用
strings.Compare(a.Name, b.Name)而非a.Name ，避免 Unicode 排序异常（如带重音字符） - 对指针字段排序前先判空，否则 panic：
a.User != nil && b.User != nil && a.User.ID
sort.Slice(items, func(i, j int) bool {
if items[i].Status != items[j].Status {
return items[i].Status < items[j].Status // pending < done
}
return items[i].CreatedAt.After(items[j].CreatedAt) // 新的在前
})
sort.SliceStable 仅在需要保序时才用
如果你的切片里已有部分有序元素（比如按时间插入后想再按状态分组，但同状态内保持原有时间顺序），就得用 sort.SliceStable。它保证相等元素的相对位置不变，代价是比 sort.Slice 稍慢（尤其大数据量时用的是更保守的排序算法）。
容易被忽略的一点：「相等」由你的 Less 函数定义——只要 Less(i,j)==false && Less(j,i)==false，就视为相等。所以多字段排序中，如果只比了第一字段，第二字段差异会被忽略，稳定性的保障范围就变小了。
- 日常业务排序（如列表页按单字段排序）基本不需要
Stable版本 - 数据库分页 + 合并排序场景可能需要：比如两次查询结果按同一字段合并，又希望原始查询内的顺序保留
- 没有
sort.SliceStable的旧 Go 版本（
自定义类型排序别忘了导出字段
如果排序目标是自定义 struct，而字段是小写开头（未导出），sort.Slice 闭包里依然能访问——因为闭包在包内，不是跨包调用。但一旦你把排序逻辑抽到另一个包里（比如 utils 包），就会编译失败：cannot refer to unexported field。
这不是排序函数的问题，是 Go 的可见性规则。解决方式只有两个：要么字段导出（首字母大写），要么提供导出的 Getter 方法。
- 导出字段最简单，但破坏封装性；Getter 更安全，但每次比较都要调方法，有微小开销
- JSON 标签（
json:"name"）不影响排序，别指望靠它自动映射 - 嵌套结构体字段访问要明确层级：
a.Profile.Address.City ，别漏掉中间零值检查
真正麻烦的从来不是怎么写排序，而是排序字段来源不可靠（比如来自 HTTP query 的字符串需转 int）、或排序逻辑随业务迭代频繁变更——这时候把 Less 函数单独提成变量或方法，比硬编码在 sort.Slice 里更容易测试和复用。
