sort.sort panic 的原因是未完整实现 sort.interface 的三个方法或类型不匹配；应为结构体定义新类型并实现接口，或用 sort.slice 临时排序。
为什么 sort.Sort 总是 panic：nil pointer 或 missing method？
因为没实现 sort.Interface 的三个方法，或者其中某个返回了 nil（比如 less 里用了未初始化的切片）。go 不会自动帮你检查接口实现是否完整，只有运行时调用 sort.Sort 才暴露问题。
-
len()必须返回int，不能是int64或其他类型 —— 类型不匹配会导致编译失败 -
Swap(i, j int)里的i、j是索引，不是值；传错会越界 panic，常见于手写循环时用range的 value 而非 index -
Less(i, j int)必须严格满足「自反性、传递性、反对称性」，否则排序结果不可预测，比如用float64比较时没处理NaN
如何给自定义结构体快速支持 sort.Sort？
最稳妥的方式是为结构体定义一个新类型，并为该类型实现 sort.Interface。不要直接在原 Struct 上实现——容易污染 API，也违背封装原则。
- 如果只是临时按某字段排序，优先用
sort.Slice（Go 1.8+），它接受任意切片和闭包，无需定义新类型 - 若需复用（比如多个地方都要按
Name升序），定义如type ByName []User，再实现三个方法 - 注意：实现
Less时别写成a[i].Name —— 这里 <code>a是接收者，应是s[i].Name （<code>s是接收者变量名）
sort.Slice(users, func(i, j int) bool { return users[i].Age < users[j].Age }) sort.SliceStable 和 sort.Slice 差在哪？
前者保持相等元素的原始顺序，后者不保证。这对业务有实际影响：比如先按时间排序、再按状态稳定排序，能保留“同状态内时间先后”的语义。
- 性能上，
sort.SliceStable略慢（多一次比较和内存拷贝），但差异通常可忽略 - 底层算法不同：
sort.Slice用 introsort（快排+堆排+插排混合），sort.SliceStable用 pdqsort 的稳定变种 - 兼容性无差别，两者都是 Go 1.8 引入，无需额外依赖
排序含指针或嵌套字段时最容易漏什么？
空指针解引用 —— 尤其当切片里混着 nil 元素时，Less 函数里直接访问 x.Field 就 panic。
立即学习“go语言免费学习笔记（深入）”；
- 务必在
Less开头加if x == nil || y == nil { return false }或按业务逻辑定义nil的排序位置 - 嵌套字段如
user.Address.City，要逐层判空：user.Address != nil && user.Address.City != "" - 字符串比较用
strings.ToLower前，先确认非空；否则ToLower(nil)会 panic
事情说清了就结束。真正难的不是写那三个方法，而是想清楚「相等怎么定义」「空值放前面还是后面」「大小写是否敏感」——这些逻辑一旦写进 Less，就很难被测试覆盖全。