sort.Slice 是首选方案，因它无需实现 sort.Interface、安全可读、支持灵活的多字段排序逻辑，且避免了老式写法的冗余与不可维护性。
sort.Slice 为什么是首选方案
Go 1.8 引入的 sort.Slice 是目前最直接、安全、可读性最好的多字段排序方式。它不要求类型实现 sort.Interface，避免了冗长的接口实现和潜在的 panic（比如对 nil 切片调用 sort.Sort 时不会自动检查）。它的排序逻辑完全由你传入的闭包控制，字段顺序、升序降序、空值处理都一目了然。
常见错误是仍沿用老式写法：先定义一个结构体类型，再为它实现 Less、Len、Swap —— 这在单次排序、类型固定时还行，但一旦要动态切换排序字段或组合条件，代码立刻变得臃肿且难以复用。
- 必须确保切片非 nil；
sort.Slice(nil, ...)会 panic - 闭包中访问切片元素时，索引越界不会被
sort.Slice捕获，错误会在运行时暴露 - 闭包捕获外部变量（如排序字段名）时要注意生命周期，避免意外引用已释放内存（虽在切片排序场景中较少见，但闭包嵌套深时需留意）
字符串字段排序要注意大小写和 locale
直接用 a.Name 是字节序比较，对 ASCII 安全，但遇到中文、德语变音符号（ä, ö）、俄文字母等会出错。例如 <code>"Zebra" 返回 true（因为 'Z' ASCII 码小于 'a'），这通常不符合用户预期。
正确做法是统一转小写后比较，或使用 strings.CaseInsensitiveCompare（Go 1.21+）：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
sort.Slice(items, func(i, j int) bool {
a, b := items[i], items[j]
if a.Status != b.Status {
return a.Status < b.Status // 状态升序
}
if strings.ToLower(a.Name) != strings.ToLower(b.Name) {
return strings.ToLower(a.Name) < strings.ToLower(b.Name) // 名称忽略大小写升序
}
return a.ID < b.ID // ID 升序兜底
})
- 频繁调用
strings.ToLower有分配开销，若排序数据量大且字段稳定，可预先计算并缓存小写版本字段（如加LowerName string字段） - 需要按语言习惯排序（如德语中 "ä" 视为 "ae"）时，应使用
golang.org/x/text/collate包，而非简单 lowercase - 数据库常用排序规则（如 MySQL utf8mb4_0900_as_cs）无法直接映射到 Go 字符串比较，需明确业务是否要求与 DB 一致
多字段混合升降序的布尔表达式写法
Go 不支持像 SQL 那样写 ORDER BY status ASC, name DESC, id ASC，必须手动展开为嵌套 if 或链式布尔运算。关键原则是：**优先级高的字段在前，相等时才比下一个；每个字段内部用升序/降序逻辑反转比较方向**。
错误写法：a.Status b.Name —— 这会导致只要 a.Status 更小，就忽略 name 比较，完全破坏多级逻辑。
正确模式是“短路链式”：
sort.Slice(items, func(i, j int) bool {
a, b := items[i], items[j]
// status 升序
if a.Status != b.Status {
return a.Status < b.Status
}
// name 降序 → 把比较方向反过来
if a.Name != b.Name {
return a.Name > b.Name
}
// id 升序
return a.ID < b.ID
})
- 降序字段不能简单写
return a.Name > b.Name后直接 return，必须用 if 分支隔离，否则后续字段失效 - 浮点字段排序要小心 NaN：任何与 NaN 的比较（
==、、<code>>）都返回 false，需单独判断math.IsNaN - 时间字段建议用
Before/After方法，而非直接比较UnixNano()，避免时区或单调时钟问题
性能敏感场景下避免重复计算
如果某个排序字段需要复杂计算（如从 JSON 字段解析、调用函数生成派生值），而该字段在排序过程中被反复读取（每次 Less 调用都算一遍），就会显著拖慢速度。Go 的 sort 算法平均比较次数是 O(n log n)，意味着一个 10 万条记录的切片，该字段可能被计算数十万次。
解决方案不是提前“预计算所有字段”，而是按需缓存——在 sort.Slice 外部构造带缓存字段的临时切片：
type sortableItem struct {
orig Item
score float64 // 预计算的得分
tagList []string // 预展开的标签切片
}
tmp := make([]sortableItem, len(items))
for i, it := range items {
tmp[i] = sortableItem{
orig: it,
score: computeScore(it), // 只算一次
tagList: strings.Fields(it.Tags),
}
}
sort.Slice(tmp, func(i, j int) bool {
if tmp[i].score != tmp[j].score {
return tmp[i].score > tmp[j].score // 降序
}
return len(tmp[i].tagList) < len(tmp[j].tagList)
})
- 临时切片会额外占用内存，但换来了确定的 O(n) 预计算 + O(n log n) 比较，比 O(n log n × cost_per_computation) 更可控
- 如果原始切片很大且只排序一次，这种“空间换时间”很划算；若需频繁重排且内存受限，应优化计算函数本身（如加 memoize 或用更高效算法）
- 注意不要在闭包里修改
tmp中的指针或 map/slice 元素，否则可能影响原始数据
