sort.Slice 是排序结构体切片的首选方法，无需定义新类型或实现 Len/Less/Swap 方法，写法简洁直观；常见错误是比较函数中误写为 return people[i].Age。
用 sort.Slice 排结构体切片最直接
绝大多数场景下，sort.Slice 是首选：它不要求你定义新类型、不需实现 Len/Less/Swap 三个方法，写法扁平，字段访问直观。
常见错误是把比较函数写成 return people[i].Age ——下标写死导致全乱；或是漏掉提前解包，反复取 <code>people[i] 造成冗余开销。
- 必须用
people[i]和people[j]，不能硬编码下标 - 推荐先赋值：
a, b := people[i], people[j]，提升可读性，也避免多次字段访问（尤其嵌套深或含方法调用时） - 切片必须可寻址：不能传字面量如
sort.Slice([]Person{{}}, ...)，会编译失败
slices.SortFunc 要求泛型约束，不适用于动态字段访问
slices.SortFunc 是 Go 1.21 加入的泛型版排序，签名是 func(T, T) int，它要求元素类型 T 明确且可比较，不接受闭包里做字段提取或类型断言。
比如你想按 user.Profile.City 排序，或者字段是 *string 需判空，slices.SortFunc 就没法直接用——它无法在比较函数里写 if a.Name == nil 这类逻辑。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 适合场景：已封装好的泛型容器，如
type UserSlice []User，且排序逻辑只依赖User的公开可比较字段 - 不能传
strings.Compare当参数，类型推导失败；得写func(a, b string) int { return strings.Compare(a, b) } - 多字段排序要手动链式写：
if a.Name != b.Name { return strings.Compare(a.Name, b.Name) } return a.Age - b.Age
需要稳定排序？别信 sort.Slice，改用 sort.SliceStable
sort.Slice 底层是 pdqsort，**不保证稳定性**。所谓“稳定”，是指当两个元素按排序字段完全相等时，它们在原切片中的相对顺序不变。
这在真实业务里很关键：比如先按状态分组（"pending" / "done"），再按创建时间升序——如果状态相同的几条记录原始顺序是 A→B→C，排序后必须仍是 A→B→C，否则前端列表会跳变。
- 只要排序键可能重复，又依赖原始次序，就必须用
sort.SliceStable - 性能略低于
sort.Slice，但差异通常可忽略；别为了省几纳秒牺牲语义正确性 -
slices.SortFunc没有对应的Stable版本，要稳定就得退回sort.SliceStable+ 闭包
什么时候还该实现 sort.Interface？
只有两种情况值得走老路：一是你要把排序逻辑复用在多个地方，且类型固定（比如 Courses 切片总按 Name 排）；二是你正在封装一个可导出的公共库，需要明确暴露排序能力。
否则，为单次排序去定义新类型、实现三个方法，纯属增加认知负担。现在 sort.Slice 已足够表达复杂逻辑，比如带空值判断、忽略大小写、时间比较等。
- 实现
Less时，务必只比i和j，别引入外部变量或状态 - 若结构体字段未导出（小写开头），
sort.Interface依然能访问——但sort.Slice同样可以，没区别 - 指针切片（
[]*Person）排序时，sort.Slice里解引用更直白：a, b := *people[i], *people[j]
真正容易被忽略的是稳定性与空值处理的组合：既要用 sort.SliceStable，又得在比较函数里显式检查 nil 或零值，这两件事缺一不可。写完排序逻辑后，随手加个含重复字段+空指针的测试用例，基本就能避开大半坑。
