Go排序需明确选择：基础类型用sort.Ints等专用函数，结构体用sort.Slice，重复使用才实现sort.Interface；选错将导致编译失败、panic或结果错乱。
Go 里排序不能“自动推断类型”，必须明确路径：基础类型用 sort.Ints/sort.Strings，结构体或复杂逻辑用 sort.Slice，复用多次才考虑实现 sort.Interface。选错会导致编译失败、panic 或排序结果错乱。
基础类型直接调用专用函数
对 []int、[]string、[]float64 这类标准切片，优先用 sort.Ints、sort.Strings、sort.Float64s：
- 它们零闭包开销、语义清晰、编译期类型检查严格——传
[]int64或[]interface{}会直接报错，避免运行时 panic - 只支持升序；要降序得换
sort.Slice，或套一层sort.Reverse(sort.IntSlice(s)) - 不接受含
nil的切片（如[]*string），也不接受数组——想排[5]int，得先转成arr[:] - 函数原地修改，不返回新切片；传
nil会 panic，需提前判空
示例：sort.Strings(names) 按字典序升序；sort.Ints(nums) 按数值升序。
结构体或多字段排序用 sort.Slice
sort.Slice 是 Go 1.8+ 后最常用方式，闭包里写比较逻辑，不用改结构体定义：
立即学习“go语言免费学习笔记（深入）”；
- 切片必须可寻址：不能写
sort.Slice([]Person{{}}, ...)，得先赋值给变量再传 - 结构体字段必须导出（首字母大写），否则闭包里读不到值
- 多条件排序用
if-else分层判断，别堆&&——比如“先按年龄升序，同龄按姓名降序”要写成：if p[i].Age != p[j].Age { return p[i].Age < p[j].Age }; return p[i].Name > p[j].Name - 闭包里禁止捕获循环变量（如
for _, v := range items中的v），必须通过索引访问：items[i].Field - 含
nil指针（如[]*Person）会 panic，得提前过滤或在闭包里判空
需要稳定排序时必须用 sort.SliceStable
当排序键有重复（如多人分数相同），又要求保持原始输入中它们的相对顺序（比如提交先后、日志时间戳顺序），普通 sort.Slice 不保证这点——它底层是 pdqsort，不稳定：
-
sort.SliceStable接口和sort.Slice完全一致，只是算法换成稳定版本（如归并） - 性能略低，但仅在“键重复 + 顺序敏感”场景下才值得切换
- 典型场景：分页列表按状态分组后，同状态项按创建时间升序；或事件流按类型聚合后，同类事件按原始到达顺序保留
-
sort.Stable是配套sort.Interface的稳定版，但日常几乎用不到
示例：sort.SliceStable(students, func(i, j int) bool { return students[i].Score > students[j].Score }) ——分数相同的两人，原始位置靠前的仍排前面。
复用排序逻辑才实现 sort.Interface
只有两种情况值得封装成新类型并实现 Len/Less/Swap：
- 同一规则在多个地方反复使用（如“商品按价格降序”出现在 API、后台任务、缓存预热三处）
- 要兼容老版本 Go（
注意点：
- 必须定义新类型（如
type ByPrice []Product），不能直接在原 struct 上加方法 -
Less方法里禁止修改数据，只做比较；Swap必须真正交换底层数组元素 - 少实现任一方法，编译报错：
does not implement sort.Interface -
Less必须满足严格弱序（比如Less(i,i)恒为false），否则结果未定义
稳定性仍是隐藏坑：即使实现了 sort.Interface，调用 sort.Sort 依然不稳定；要稳定，得显式调用 sort.Stable。
