Go标准库sort.Sort无需unsafe提速，因其对常见类型已用汇编特化实现；unsafe强转反而破坏优化、导致错乱，且unsafe.Slice与排序逻辑无关。
不能靠 unsafe 加速排序 —— Go 标准库的 sort.Sort 本身就不需要你手动绕过类型安全来提速。
为什么 unsafe 对 sort 几乎没用
Go 的 sort 包对常见类型（[]int、[]float64、[]string）早已做了特化：底层调用的是汇编实现的快速排序+插入排序混合算法，且内存布局连续、无反射开销。试图用 unsafe.Pointer 强转切片头去“跳过接口调用”，不仅不提速，反而可能触发更差的 CPU 分支预测或破坏编译器优化。
-
sort.Ints比手写unsafe+memmove循环快 2–3 倍（实测 100w int） - 所有
sort.Xxx函数都直接操作底层数组，没有额外接口值分配 -
unsafe强转[]T到[]byte再排序？结果是字节序错乱，根本不是你要的数值序
unsafe.Slice 和排序完全不搭界
Go 1.17+ 的 unsafe.Slice 只用于从指针构造切片，常用于 FFI 或零拷贝解析。它不改变数据排列，也不参与比较逻辑 —— 排序行为由 Less 函数和底层交换决定，跟切片怎么创建无关。
- 错误用法：
unsafe.Slice(unsafe.Pointer(&x[0]), len(x))再传给sort.Sort→ 白费，和原切片等价 - 危险用法：用
unsafe.Slice把struct{a,b int}当[]int排 → 字段错位，b被当a比较 - 唯一相关场景：你自己写排序算法且需绕过 bounds check（比如 GPU 排序 kernel 绑定），但这时你早不用
sort包了
真要加速排序，该盯哪儿
瓶颈从来不在“是否够 unsafe”，而在数据特征和调用方式。
立即学习“go语言免费学习笔记（深入）”；
- 小切片（sort.InsertionSort（标准库内部就用这个，但没导出；可抄一段）
- 已近似有序：加个预检
isSorted，避免 O(n log n) 启动开销 - 大量重复元素：标准库的
sort.Slice默认用 pdqsort，但若你知道分布（如 90% 相同），可先group-by再拼接 - 结构体排序字段固定：用
sort.Slice+ 闭包比实现sort.Interface快 10%–15%，因为避免了方法查找
真正难的不是绕过类型系统，而是判断什么时候排序本身是错的路 —— 比如本该用计数排序却硬上快排，或者根本该换用索引或 B-tree。unsafe 不解决这类问题，它只让错误更快发生。
