直接用 sort.Slice 就够了，因其简洁、语义清晰且性能接近原生接口；仅当需固化排序规则或封装自定义集合时才手动实现 sort.Interface。
为什么直接用 sort.Slice 就够了，还要实现 sort.Interface？
大多数时候你真不需要手写 sort.Interface。Go 1.8 加入的 sort.Slice 能直接传比较函数，写法简洁、语义清晰，且性能和原生接口几乎无差别。
只有两种情况值得考虑手动实现接口：
— 你要对同一类型频繁排序（比如在多个包里都按时间倒序），想把规则“固化”进类型本身；
— 你封装了一个自定义集合结构体（如 PriorityQueue），需要和标准库其他排序/堆工具联动。
- 手写
Len/Less/Swap三方法会增加维护成本，尤其当字段名或逻辑变更时容易漏改Less -
sort.Slice的闭包捕获变量更灵活，比如按当前用户权限动态决定排序依据 - 注意：如果切片元素是指针或大结构体，
Less里取字段要避免重复解引用——这不是语法错误，但影响可读性和 CPU 缓存局部性
Less 方法里访问字段出 panic：index out of range
这是最常踩的坑：在 Less(i, j int) 里直接用 s[i].Field 却没校验 i 和 j 是否在 [0, Len()) 范围内。实际上 sort 包调用 Less 前已确保 i、j 合法，你完全不用加 if i >= len(s) || j >= len(s) 这类判断。
- panic 真正来源往往是
s本身是 nil 切片，或你在Len()里返回了错误长度（比如忘了加指针解引用：*svss） - 另一个隐蔽原因是用了 slice header 操作（如
unsafe.Slice）导致底层数组被提前释放，但Len()仍返回旧值 - 调试技巧：在
Less开头加fmt.Printf("Less(%d,%d) on len=%d\n", i, j, len(s))，快速确认是否传参越界
字符串切片按长度升序 + 字典序降序的复合排序
标准库不支持链式比较，必须在 Less 里手动写优先级逻辑。别用嵌套 if，用“短路表达式”更安全：
立即学习“go语言免费学习笔记（深入）”；
func (s ByLenThenRevName) Less(i, j int) bool {
a, b := s[i], s[j]
if len(a) != len(b) {
return len(a) < len(b) // 长度升序
}
return a > b // 相同长度时字典序降序（注意是 > 不是 <）
}
- 错误写法：
return len(a) b)—— 看似等价，但 Go 的&&/||短路特性会让它在len(a) 为 true 时跳过右边，逻辑正确；但可读性差，且一旦括号漏写易出错 - 如果字段是嵌套结构体（如
user.Profile.Name），记得检查Profile是否为 nil，否则 panic 不在Less而在字段访问时 - 这种多条件排序无法用
sort.Slice的单个闭包优雅表达，此时才显出sort.Interface的必要性
实现 sort.Interface 后调用 sort.Sort 没生效
最可能的原因是：你传给 sort.Sort 的不是指针，而原始切片变量本身不可寻址。例如：
users := []User{{Name: "a"}, {Name: "b"}}
sort.Sort(ByName(users)) // ❌ users 未被修改
正确做法是传地址，或者让类型包装的是指针：
sort.Sort(ByName(&users)) // ✅
- 根本原因：
sort.Sort内部通过Swap修改元素位置，若ByNames包装的是值副本，则Swap只动副本，原切片不变 - 更推荐的方式是定义类型时直接包装指针：
type ByName *[]User，并在Len/Less/Swap中统一解引用，避免每次调用都写& - 如果你用
sort.Slice，就完全不用操心这个——它接收切片本身，内部直接操作底层数组
真正麻烦的从来不是接口怎么写，而是搞清“谁 owns 这块内存”和“排序到底要改哪个变量”。这点不厘清，写十遍 Less 都白搭。
