sort.Slice是Go 1.8+结构体多字段排序首选，闭包内解包a,b避免重复取值，字段须导出，时间比较用Before而非==，Less只需返回布尔值。
用 sort.Slice 写多字段比较闭包最直接
Go 1.8+ 后，sort.Slice 是结构体切片多字段排序的事实标准。它不要求你定义新类型或实现 Len/Less/Swap，所有逻辑收在一个闭包里，可读性强、修改成本低。
常见错误是把多级判断写成嵌套 if 或漏掉短路逻辑，导致部分字段没生效；或者误用 == 判断字符串相等后再比下一级——其实 Less 函数只需返回布尔值，不关心“是否相等”，只关心“是否该排在前面”。
- 字段必须导出（首字母大写），否则闭包内访问不到值
- 闭包参数
i、j是下标，不是元素本身；别写成people[0].Name这种硬编码 - 推荐先解包：
a, b := people[i], people[j]，避免重复取字段（尤其含方法调用或深层嵌套时） - 时间比较必须用
a.CreatedAt.Before(b.CreatedAt)，不能直接用操作符
例如按状态升序、创建时间降序：
<pre class="brush:php;toolbar:false;">sort.Slice(orders, func(i, j int) bool {
a, b := orders[i], orders[j]
if a.Status != b.Status {
return a.Status < b.Status // 升序
}
return a.CreatedAt.After(b.CreatedAt) // 降序：新创建的排前面
})
字符串字段忽略大小写？闭包里转小写再比
sort.Strings 不支持忽略大小写，<code>sort.Slice 也没内置选项，但闭包里加 strings.ToLower 就行。注意别在闭包外预处理整个切片——那会额外分配内存，且无法复用原切片引用。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每次比较都调用
strings.ToLower看似低效，但实际开销远小于手写排序或反射方案 - 如果字段是
*string，必须先判空：a.Name != nil && b.Name != nil && strings.ToLower(*a.Name) - 避免用
strings.Compare：它返回 -1/0/1，而sort.Slice闭包只要求bool，直接用更简洁
示例：
<pre class="brush:php;toolbar:false;">sort.Slice(users, func(i, j int) bool {
a, b := users[i], users[j]
if a.Name == nil || b.Name == nil {
return a.Name != nil // nil 排后面
}
return strings.ToLower(*a.Name) < strings.ToLower(*b.Name)
})
需要稳定排序？换用 sort.SliceStable
sort.Slice 底层是 pdqsort，**不保证稳定性**。所谓稳定，是指当多个元素在排序字段上完全相等时，它们在原切片中的相对顺序不变。这在分页、UI 渲染或审计日志场景中很关键。
-
sort.SliceStable行为和sort.Slice完全一致，只是换了个底层算法（类似归并），性能略低但可预期 - 别试图用
sort.Stable(sort.Interface)包裹sort.Slice—— 它不接受闭包，只能作用于实现了接口的类型 - 如果排序字段本身含唯一 ID，稳定性就无关紧要；但若按状态、分类等高频重复字段排，就该默认用
Stable版本
动态字段名（如运行时传 "status"）怎么办？别硬塞反射
Go 没有 Python 那样的 key=lambda x: getattr(x, field)，硬用 reflect 做动态字段访问不仅慢（5–10 倍性能损耗），还极易 panic（字段不存在、不可导出、类型不匹配）。真实项目中应避免。
- 优先用代码生成或枚举字段：比如定义
type SortField int，配合 switch 构建不同闭包 - 若真需运行时决定，封装成 map[string]func(i,j int) bool，预先注册好各字段的比较函数，查表调用
-
slices.SortFunc（Go 1.21+）不适用：它要求泛型约束，无法在比较函数里做字段提取或空值判断
真正容易被忽略的是：动态排序往往意味着前端传参或配置驱动，这时候更该在 HTTP handler 层就校验字段名白名单，而不是把校验逻辑拖进排序闭包里。
