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)，不能直接用操作符
例如按状态升序、创建时间降序：
sort.Strings
- 每次比较都调用
strings.ToLower看似低效，但实际开销远小于手写排序或反射方案 - 如果字段是
*string，必须先判空：a.Name != nil && b.Name != nil && strings.ToLower(*a.Name) - 避免用
strings.Compare：它返回 -1/0/1，而sort.Slice闭包只要求bool，直接用更简洁
示例：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
sort.SliceStable
-
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 层就校验字段名白名单，而不是把校验逻辑拖进排序闭包里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
