要判断两个 slice 是否共享同一底层数组，需用 unsafe 比较其 data 指针：先取 slice 变量地址转 *reflect.SliceHeader，再比较 Data 字段；空 slice 需额外处理地址是否相同，nil slice 不能仅凭 Data 判断。
怎么用 unsafe 比较两个 slice 的底层数组是否相同
Go 语言中，slice 本身不包含数据，只包含指向底层数组的指针、长度和容量。要判断两个 slice 是否共享同一块内存，最直接的方式是对比它们的底层指针——也就是 slice header 中的 data 字段。
标准库不暴露 slice header，但可通过 unsafe 和 reflect 获取：
func sameBackingArray[T any](a, b []T) bool {
if len(a) == 0 || len(b) == 0 {
return &a == &b // 空 slice 可能 data==nil，但不能仅靠 data 判断
}
h1 := (*reflect.SliceHeader)(unsafe.Pointer(&a))
h2 := (*reflect.SliceHeader)(unsafe.Pointer(&b))
return h1.Data == h2.Data
}
-
unsafe.Pointer(&a)是关键：必须取slice变量本身的地址，不是&a[0]（后者可能 panic 或指向错误位置） - 空
slice的Data字段可能是0或任意值，不能单靠Data相等断言共享；此时若变量地址相同（&a == &b），才真正是同一个 slice 实例 - 该方法对
nilslice 也适用，但要注意nilslice 的Data是0，多个nilslice 会误判为“共享”，所以需额外处理
为什么不能用 == 或 reflect.DeepEqual
Go 规定 slice 类型不可比较：== 会编译报错；reflect.DeepEqual 比较的是元素值是否相等，完全不涉及底层数组。
-
==报错信息是：invalid operation: cannot compare a == b (operator == not defined on []int) -
reflect.DeepEqual([]int{1,2}, []int{1,2})返回true，哪怕它们来自完全无关的数组 - 即使两个 slice 元素全等、长度容量一致，也不代表共享底层数组——这正是容易混淆的点
哪些场景下必须检查底层数组共享性
典型需求集中在避免意外修改和内存安全上，不是“好奇”，而是“不得不防”。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 实现
CopyOnWrite逻辑时：只有当写入会覆盖原数据，才需要复制底层数组 - 函数接收
[]byte并做 in-place 解析（如解析 protobuf、JSON）：若调用方后续还要读原始数据，你改了就坏了 - 池化
[]byte时（如sync.Pool）：归还前需确认没被外部保留指针，否则引发 use-after-free - 调试内存泄漏：发现某个大数组一直不被 GC，可沿 slice 链路查谁还持有它的
Data指针
容易踩的坑和兼容性注意点
这个技巧依赖 unsafe 和 reflect.SliceHeader，看似简单，实则边界多。
-
reflect.SliceHeader结构体在不同 Go 版本中字段顺序/大小未保证稳定，虽然目前所有版本都一致（Data/Len/Cap），但官方文档明确说“不承诺兼容”，生产环境慎用 - Go 1.21+ 引入了
unsafe.Slice和更安全的切片操作，但仍未提供 header 检查的替代方案 - CGO 开启时，某些运行时优化可能导致
data地址被重排（极少见，但测试环境与生产环境行为可能不一致） - 如果 slice 来自
string转换（[]byte(s)），其底层数组不可写，但指针仍可比——这点常被忽略，误以为“能比就代表能改”
真正难的不是怎么比，而是比完之后要不要 copy、什么时候 copy、copy 多大范围——这些得结合业务语义，unsafe 只负责告诉你“它们是不是同一块内存”。
