slice类型转换本质是header重解释而非数据拷贝，仅复制指针、长度、容量字段，源与目标元素类型必须完全一致，转换后共享底层数组。
slice 类型转换本质是 header 重解释，不是数据拷贝
Go 中将 []string 转为自定义类型如 stringsLongestFirst（定义为 []string 的别名），不触发底层数组复制，只复制 slice header——即 12 字节（32 位）或 24 字节（64 位）的指针、长度、容量字段。这和 C 的 reinterpret_cast 类似，是编译期允许的安全 reinterpretation。
常见误解是把它当成“类型断言”或“泛型隐式转换”，其实它连运行时开销都没有，更不涉及接口装箱或反射。
- 必须满足：源与目标 slice 类型元素类型完全一致（如都是
string），且无额外字段（不能含非导出字段的嵌套结构） - 非法示例：
[]int→[]string会编译失败；type S struct{ s []string; _ int }→[]string同样非法 - 效果可验证：转换后调用
sort.Sort()，原切片内容同步变更，证明底层数组被共享
为什么 sort.Sort(stringsLongestFirst(myStrings)) 能原地生效
因为 stringsLongestFirst 是 []string 的命名类型，其 Swap 方法直接操作 myStrings 底层数组的同一内存位置。所有排序逻辑都落在原始 header 指向的数据上。
如果你误写成 sort.Slice(myStrings, func(i, j int) bool { ... })，虽然也能工作，但它是通过闭包捕获并间接访问元素，无法复用已有类型定义，且每次比较都要重新计算索引逻辑，稍多一层函数调用开销。
-
sort.Sort+ 自定义类型：零分配、零额外函数调用、完全内联友好 -
sort.Slice：需传入闭包，闭包变量捕获带来轻微逃逸可能，对极小 slice（ - 注意：自定义类型必须完整实现
Len/Less/Swap，缺一不可，否则编译报错missing method XXX
预分配容量比类型转换更能影响 slice 性能
类型转换本身开销趋近于零，但若你在转换前的 slice 构建阶段没预分配容量，append 引发的多次底层数组扩容（复制旧数据 + 分配新内存）才是真正的性能杀手。
比如处理百万级字符串列表时，未预分配的 result := []string{} 可能触发 18 次扩容，而 result := make([]string, 0, len(inputs)) 直接规避全部扩容。
- 扩容代价：每次复制 O(n) 元素，且新分配内存可能引发 GC 压力
- 类型转换无法掩盖扩容缺陷：即使你后续用
stringsLongestFirst(result)排序，扩容已发生的开销无法收回 - 真实瓶颈往往在数据组装阶段，而非排序阶段——先确保
make(..., 0, N)，再考虑怎么排
unsafe.Slice 和 reflect.SliceHeader 不该是首选方案
虽然 Go 1.17+ 提供了 unsafe.Slice，且你可以手动构造 reflect.SliceHeader 来绕过类型系统，但这些属于非安全路径，破坏类型检查，且极易因底层数组生命周期管理不当导致 panic 或静默内存错误。
例如：从局部数组取 slice 后转成其他类型，局部数组函数返回即销毁，后续访问就是悬垂指针。
- 标准类型转换（如
T(s)）由编译器保证安全，无需unsafe包，也不需要//go:unsafe注释 -
unsafe.Slice适用场景极窄：如对接 C ABI、零拷贝网络包解析等，普通业务逻辑中几乎不需要 - 一旦用了
unsafe，你就得自己负责整个内存生命周期——这比写对排序逻辑难得多
