Go中无法超越sort.Ints性能，因其采用深度优化的introsort；高性能指不拖慢、不爆内存、不触发GC颤抖；结构体排序应优先用sort.Sort避免闭包开销，需实现Len、Less、Swap且接收者为指针。
go 里想靠“自己写排序”压过 sort.ints，基本没戏——标准库的 sort.ints 是 introsort（快排+堆排+插排混合），已深度汇编优化，且自动降级。所谓“高性能”，不是比它快，而是**在特定约束下不拖慢、不爆内存、不触发 gc 颤抖**。
用 sort.Sort + 自定义 Interface 替代 sort.Slice
百万级结构体排序变慢，主因是 sort.Slice 的闭包比较函数引发接口动态调度和 CPU 缓存失效。直接换 sort.Sort 能内联比较逻辑，消除调用开销。
- 必须实现三个方法：
Len、Less、Swap，缺一不可；接收者统一用指针（*MySlice），否则Less和Swap行为不一致会 panic -
Less里别重复取字段，比如slice[i].CreatedAt.Unix()写两次 → 提前存到局部变量leftTS, rightTS - 如果只排一个字段（如
int64），别包装结构体，直接用sort.Ints或sort.SliceInts，它们走纯汇编路径
对大结构体排序，先转索引切片再间接比较
当结构体含 []byte、string 或指针字段时，交换操作成本高（要复制底层数据或更新指针）。此时排序本身不移动结构体，只移动索引。
- 构造
indices := make([]int, len(data))，填0,1,2,... - 用
sort.Slice(indices, func(i, j int) bool { return data[indices[i]].Score - 排序完按
indices顺序访问原数组，避免任何结构体拷贝 - 注意：此法不改变原切片顺序，若需真正重排，最后用
append或预分配新切片重建
Top-K 场景别硬排全量，改用 container/heap
只要前 10 名、前 100 名，排序全量是典型浪费。container/heap 构建小顶堆后逐个 Pop，时间复杂度从 O(n log n) 降到 O(n log k)。
- 别手写
heap.Sort——它不存在，标准库没这个函数；必须实现Len/Less/Swap，再调heap.Init和循环heap.Pop - 升序取 Top-K，就用小顶堆（
Less(i,j) return item[i] ），每次 <code>Pop出当前最小值，堆里始终留最大 K 个 - 堆大小固定为 K，
Push前先比堆顶：若新元素 ≤ 堆顶，直接跳过，省去入堆和下沉开销 - 注意
Pop返回interface{}，必须类型断言，例如v := heap.Pop(h).(MyItem)
大数据量排序前暂停 GC 并预分配容量
一次 500ms 以上的排序可能横跨多个 GC 周期，尤其结构体含 slice 或 map 时，GC 扫描开销会叠加进耗时。
- 离线批处理场景可临时停 GC：
old := debug.SetGCPercent(-1); defer debug.SetGCPercent(old)，但线上服务禁用 - 若排序后要返回新切片，提前
make([]T, len(src))，避免append过程中多次扩容复制 - 结构体字段顺序影响缓存友好性：把高频比较字段（如
Timestamp int64）放在前面，减少 CPU cache line 跨越 - 别在比较函数里做任何非计算操作：锁、日志、HTTP 调用、
time.Now()——这些会把 CPU 时间彻底拖垮
真正卡性能的往往不是算法本身，而是字段访问模式、内存布局和 GC 时机。写完排序逻辑后，一定要用 go tool pprof 看 CPU profile 里是不是堆在 runtime.mallocgc 或 runtime.scanobject 上——那说明你在跟 GC 抢时间。
