slice类型转换仅复制SliceHeader的24字节，不拷贝底层数组；合法前提为元素类型完全一致且无非导出字段，非法如[]int→[]string会编译失败。
slice 类型转换不触发底层数组拷贝
Go 中两个元素类型相同的 slice 类型之间转换（比如 []string → 自定义 type MyStrings []string），底层只复制 SliceHeader 的三个字段（array、len、cap），共 24 字节（64 位系统）。这不是“深拷贝”，也不访问底层数组内存，更不调用 mallocgc 或触发 GC。
常见误判场景：MyStrings(s) 被当成值拷贝整个数组，其实只是 header 按位复制；只要底层数组没被扩容或重分配，转换前后共享同一块内存。
- ✅ 合法前提：源与目标 slice 的元素类型完全一致，且无非导出字段（如
[]int↔type Ints []int） - ❌ 非法示例：
[]int→[]string编译失败；含私有字段的 struct slice 无法安全转换 - ⚠️ 注意：转换后若对新 slice 做
append，仍可能触发底层数组扩容——这和转换本身无关，而是append的行为
sort.Slice 与自定义类型排序的开销差异
使用 sort.Slice（如 sort.Slice(myStrings, func(i,j int) bool { ... })）和自定义类型实现 sort.Interface，在内存分配上没有本质区别：两者都只传递 slice header，零拷贝底层数组。
但实际性能差异来自函数调用方式：sort.Slice 接收闭包，每次 Less 调用需间接跳转；而自定义类型方法是直接调用（尤其内联后），少了闭包环境捕获开销。不过这个差异通常微乎其微，除非排序量极大且 Less 极轻量。
- ✅ 优先用
sort.Slice：简洁、无需额外类型声明、维护成本低 - ✅ 自定义类型适合复用场景：多个函数共用同一排序逻辑时，避免重复写闭包
- ⚠️ 别为“避免类型转换”而硬套
sort.Slice：如果已有现成类型且排序逻辑稳定，没必要改
哪些操作会悄悄打破零拷贝假定
表面看是类型转换，实则底层已发生数组复制的操作，容易被忽略：
-
s = s[:len(s)+1]：越界伸长会 panic，但在 panic 前 runtime 已检查容量，若len+1 > cap，会调growslice→ 底层数组搬迁 -
copy(dst, src)目标dst容量不足时不会自动扩容，但若你误以为dst和src是同一类型就能“直接转”，却忘了dst是新make出来的空 slice，那 copy 就是纯内存搬运，不是零成本视图切换 - 把转换后的 slice 传给接收
interface{}的函数（如fmt.Printf("%v", myTypedSlice)），某些 Go 版本中可能因接口装箱导致 header 逃逸到堆（取决于具体实现和逃逸分析强度）
预分配 + 类型转换才是真实优化组合
类型转换本身几乎无成本，但若底层数组本身因反复 append 扩容而多次搬迁，再怎么“零拷贝转换”也掩盖不了总拷贝量大的事实。
真正压低内存压力的方式，是把预分配和类型转换配合使用：
- 先用
make([]string, 0, estimated)预留足够容量，避免扩容拷贝 - 再用
MyStrings(s)转换，获得语义清晰的类型，同时保持原数组引用 - 最后传给
sort.Sort或其他函数，全程不新增堆分配
最容易被忽略的一点：类型转换不延长底层数组生命周期，它只是 header 复制；数组是否回收，取决于所有持有该 array 指针的 slice 是否都已离开作用域。哪怕你转了十次类型，只要有一个 slice 还活着，那块内存就不会被 GC。
