sort.Slice 是 Go 1.8 起最直接的自定义排序方式，通过闭包定义比较逻辑，直接操作原切片但会改变原顺序，需注意 nil 指针 panic 和类型明确性；sort.Sort 需实现 Len/Less/Swap 接口，适合复用场景；字符串排序应预处理大小写或使用 collate 包；数值切片优先用专用函数如 sort.Ints；NaN 在浮点排序中被置于末尾。
sort.Slice 是最直接的自定义排序入口
Go 1.8 引入 sort.Slice，它不依赖接口，只靠闭包定义比较逻辑，是绝大多数场景下首选。它直接操作原切片，不创建新底层数组，但会修改原顺序——这点容易被忽略。
常见错误：用 sort.Slice 对结构体字段为指针或 nil 的字段做比较，没加空值判断，直接 panic：invalid memory address or nil pointer dereference。
使用场景：按结构体某个字段升序/降序、按多级条件排序、按映射值排序等。
- 必须传入切片本身（不是指针），且类型要明确（不能是
interface{}） - 比较函数里返回
true表示「前面的元素应该排在前面」，即a 时返回true才是升序 - 若需降序，把比较符号反过来，或对结果取反：
return a.Age > b.Age
type Person struct {
Name string
Age int
}
people := []Person{{"Alice", 30}, {"Bob", 25}}
sort.Slice(people, func(i, j int) bool {
return people[i].Age <h3>sort.Sort 需要实现 sort.Interface 接口</h3><p>这是老派写法，适合需要复用同一套排序逻辑多次、或封装成可导出类型的情况。但它强制你写三个方法：<code>Len</code>、<code>Less</code>、<code>Swap</code>，稍显啰嗦。</p><p>容易踩的坑：忘记在 <code>Less</code> 方法中处理边界索引，比如直接访问 <code>s[i].Field</code> 而没确认 <code>i ；或者在 <code>Swap</code> 中用了值拷贝而非指针交换，导致实际没换。</code></p><p>性能影响：和 <code>sort.Slice</code> 基本一致，底层都走同一套快排+插入排序混合策略；但多一层接口调用开销，微乎其微。</p>
-
Len必须返回int，不能是int64或其他类型 -
Less(i, j int)的参数 i/j 是索引，不是元素值，别错当成值来比 - 如果切片元素是指针（如
[]*Person），Swap里交换的是指针本身，不是解引用后的值
字符串切片排序要注意 locale 和大小写
直接用 sort.Strings 是按 UTF-8 字节序排的，不是按语言习惯。比如中文拼音、德语变音符（ä, ö）、土耳其语的 i/I 规则，它一概不管。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
常见错误现象：英文混中文时，“苹果”排在“Banana”前面，或 “Zebra” 排在 “apple” 后面——因为大写字母 ASCII 值小于小写，而 sort.Strings 不做 case fold。
正确做法：用 strings.ToLower 预处理，或引入 golang.org/x/text/collate 包做本地化排序。
- 简单场景用
sort.Slice(ss, func(i, j int) bool { return strings.ToLower(ss[i]) - 生产环境涉及多语言，必须用
collate，否则用户投诉「排序不符合预期」几乎是必然的 - 别在循环里反复调用
strings.ToLower，可提前缓存转换结果避免重复分配
数值切片别用 sort.Slice 做简单升序
虽然能用，但没必要。Go 标准库为常见数值类型提供了专用函数：sort.Ints、sort.Float64s、sort.Uint64s 等。它们内联程度更高，编译器更容易优化，实测比 sort.Slice 快 10%–15%。
容易被忽略的点：这些函数只接受具体类型切片，不接受 interface{}，也不接受自定义别名类型——哪怕底层是 int，也得先转成裸 []int 才能用。
- 例如
type MyInts []int，不能直接传给sort.Ints，得写sort.Ints([]int(myInts)) - 浮点切片含
NaN时，sort.Float64s会把所有NaN放末尾，且相互顺序不确定——这是 IEEE 754 规定，不是 bug - 如果只是想查最大最小值，用
max/min函数（Go 1.21+）比排序快得多
真正麻烦的是嵌套结构或动态字段名排序，这时候闭包捕获变量的作用域、是否要稳定排序（sort.Stable）、以及并发安全（排序过程不能被其他 goroutine 修改底层数组）——这些细节，不真正在业务里碰几次，很难意识到它们会出问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
