直接用 sort.slice 传匿名函数易写成面条代码，因嵌套字段、空指针判断等逻辑混杂；应封装为闭包或自定义类型以提升可读性、可测试性与复用性。
为什么直接用 sort.Slice 传匿名函数会写得很乱？
当你面对嵌套字段、多级条件或需要复用比较逻辑的结构体时，直接在 sort.Slice 第二个参数里写长匿名函数，很快就会变成一行几十个点号加括号的“面条代码”。比如 users[i].Profile.Address.City 和 users[j].Profile.Address.City 反复出现，还夹杂着空指针判断和类型转换，可读性和维护性立刻崩掉。
根本问题不在语法，而在逻辑组织：比较逻辑本该是独立、可测试、可复用的单元，不该被塞进一个泛型排序调用里。
解决思路不是换函数，而是把比较逻辑提前封装——闭包就是最轻量的封装方式。
怎么用闭包提前构造比较函数？
闭包能捕获外部变量（比如排序字段名、是否倒序、空值优先级），返回一个符合 func(i, j int) bool 签名的函数。这样既保持 sort.Slice 的简洁调用，又把复杂判断收拢到一处。
- 用闭包生成比较函数，避免重复写
users[i]/users[j] - 把字段访问、空值处理、大小写敏感等逻辑全放进闭包内部，外部只传配置参数
- 闭包返回的函数可直接传给
sort.Slice，无需额外 wrapper 或中间变量
示例：按用户昵称排序，忽略大小写，空昵称排最后：
sort.Slice(users, func(i, j int) bool {
a, b := users[i].Nickname, users[j].Nickname
if a == "" { return false }
if b == "" { return true }
return strings.ToLower(a)
<p>改成闭包后：</p>
<pre class="brush:php;toolbar:false;">byNickname := func(reverse bool) func(int, int) bool {
return func(i, j int) bool {
a, b := users[i].Nickname, users[j].Nickname
if a == "" { return !reverse }
if b == "" { return reverse }
cmp := strings.ToLower(a)
<h3>闭包里要小心哪些 Go 特性陷阱？</h3>
<p>闭包本身没问题，但实际写的时候容易踩几个 Go 特有坑：</p>
- 闭包捕获的是变量引用，不是值——如果在循环里创建多个闭包，且都引用同一个循环变量（如
for _, field := range fields），所有闭包最终都会用最后一次迭代的field值。必须用field := field显式复制 - 闭包内访问结构体字段时，若字段是 nil 指针（比如
*string），直接解引用会 panic。得先判空，不能依赖 defer recover——排序过程不保证 panic 安全 - 闭包函数不能直接序列化或跨 goroutine 安全共享（除非它只读且无状态），但排序本身是单线程的，这点通常不用管
常见错误现象：panic: runtime error: invalid memory address or nil pointer dereference，往往就出在闭包里没检查 users[i].Profile 是否为 nil。
什么时候该放弃闭包，改用自定义类型？
当排序逻辑开始涉及多个字段组合（比如“先按城市升序，城市相同时按年龄降序”），或者需要预计算缓存（比如对每个字符串做一次 expensive 转换），闭包会迅速变得难维护。
这时更清晰的做法是定义一个类型，实现 sort.Interface：
type ByCityThenAge []User
func (s ByCityThenAge) Len() int { return len(s) }
func (s ByCityThenAge) Swap(i, j int) { s[i], s[j] = s[j], s[i] }
func (s ByCityThenAge) Less(i, j int) bool {
if s[i].City != s[j].City {
return s[i].City s[j].Age // 降序
}
sort.Sort(ByCityThenAge(users))
这种写法比嵌套闭包更易读、易测试、易复用，尤其适合项目中多处用到同一排序规则的场景。
真正容易被忽略的是：闭包适合“一次性的、参数驱动的简单排序”，而自定义类型适合“稳定的、业务语义明确的排序契约”。别硬撑——逻辑一复杂，就该换招。
