sort.Slice比sort.Sort更适合多维度结构体排序，因其直接接收闭包定义比较逻辑，无需实现Len/Less/Swap三个方法，避免冗余类型声明；在字段多、规则动态时更灵活可读，且不污染结构体定义。
为什么 sort.Slice 比 sort.Sort 更适合多维度结构体排序
因为 sort.Slice 允许你直接传入一个闭包作为比较逻辑，不用为每个结构体定义 Len/Less/Swap 方法，避免了冗余类型声明。尤其当结构体字段多、排序规则动态变化（比如前端传来的排序字段列表）时，sort.Slice 的灵活性和可读性明显更高。
常见错误是误用 sort.SliceStable 以为它“更安全”——其实它只保证相等元素的相对顺序，对多字段排序无实质帮助；真正影响结果的是比较函数是否满足严格弱序（即不能出现 a 同时为 true）。
- 必须确保比较函数返回
true当且仅当前者“应排在后者前面” - 多个字段组合时，要用“短路逻辑”：先比第一维，相等再比第二维，依此类推
- 注意
nil字段或空字符串的处理，否则运行时 panic 或排序错乱
如何写一个安全的多字段比较闭包（以 User 结构体为例）
假设结构体：
type User struct {
Name string
Age int
Score float64
City *string // 可能为 nil
}要按 City（升序，nil 排最后）、Age（降序）、Name（升序）排序。
关键点在于显式处理 nil 和反向逻辑：
-
City比较：先判断两边是否nil，再解引用比较；nil视为最大值 -
Age降序：写成a.Age > b.Age，而不是a.Age 再取反 - 每层比较必须用
if分支 +return，不能合并为一行布尔表达式（易出错）
示例闭包：
sort.Slice(users, func(i, j int) bool {
a, b := users[i], users[j]
<pre class="brush:php;toolbar:false;">// City: nil 排最后，否则按字典序升序
if a.City == nil && b.City != nil {
return false
}
if a.City != nil && b.City == nil {
return true
}
if a.City != nil && b.City != nil {
if *a.City != *b.City {
return *a.City < *b.City
}
}
// Age: 降序
if a.Age != b.Age {
return a.Age > b.Age
}
// Name: 升序
return a.Name < b.Name
})
立即学习“go语言免费学习笔记（深入）”；
sort.Slice 的性能陷阱：什么时候不该用它
绝大多数场景下 sort.Slice 足够快，但有两个典型瓶颈：
- 闭包捕获大量变量（尤其是大 slice 本身）会导致逃逸和额外内存分配
- 频繁调用中反复构造相同逻辑的闭包（比如 HTTP handler 里每次请求都新建闭包）
解决办法很直接：
- 把比较逻辑抽成独立函数，参数只传两个
User值，避免捕获外部作用域 - 如果排序字段固定，提前预编译比较函数（例如用 map[string]func(a,b User)bool 缓存不同策略）
- 对超大数据量（>100万），考虑用
unsafe+ 原生数组优化，但需自行保证内存安全
字段类型不一致时的兼容性处理（如 int vs int64）
Go 不允许跨类型比较，比如 a.ID (int) 和 b.ID (int64) 直接比较会编译失败。常见于 ORM 生成结构体或混用不同 SDK。
必须显式转换，且注意溢出风险：
- 优先统一底层类型（改 struct 定义），这是最安全的做法
- 若无法修改，转换时用
int64(a.ID)或int(b.ID)，但需确认值范围 ——int64转int在 64 位系统虽通常安全，32 位环境可能 panic - 字符串字段注意大小写：需要忽略大小写时用
strings.ToLower(a.Name) ，别用 <code>bytes.Compare直接比 []byte（不等价）
最容易被忽略的是浮点字段的比较：用 math.Abs(a.Score - b.Score) 判断相等，再决定是否进入下一字段；直接 <code>a.Score 在精度误差下可能导致排序不稳定。
