不能直接用 &slice[0] 获取底层指针，因为切片为空时会 panic，且该地址未必是底层数组起始位置；应使用 unsafe.Slice 或 reflect.SliceHeader 安全获取 Data 字段。
为什么不能直接用 &slice[0] 获取底层指针
很多初学者以为对切片首元素取地址就能拿到其底层数组起始地址，但这是危险且不总是正确的。如果切片长度为 0（len(slice) == 0），&slice[0] 会 panic；即使非空，它也只保证指向当前 slice 的第一个有效元素，而非整个底层数组的起始位置——尤其当 slice 是从更大数组或切片截取而来时，&slice[0] 和真实底层数组首地址可能不同。
unsafe.Slice（Go 1.17+）是最安全的替代方案
Go 1.17 引入了 unsafe.Slice，它专为从指针和长度构造切片而设计，语义清晰、无需手动计算偏移，且被 Go 官方明确支持用于此类场景。配合 unsafe.Pointer 和 reflect.SliceHeader，可以安全地“反向”获取底层数据指针。
实际做法是：先用 reflect.ValueOf 获取切片头信息，再通过 unsafe.Pointer 提取 Data 字段：
hdr := (*reflect.SliceHeader)(unsafe.Pointer(&slice)) ptr := unsafe.Pointer(hdr.Data)
注意：hdr.Data 就是该切片指向的底层数组中第一个元素的地址（即真实起始地址，与 &slice[0] 在非空时等价，但不会 panic）。
- 必须确保
slice是可寻址的（如局部变量、字段，而非函数返回的临时切片）；否则&slice可能非法 - Go 1.20+ 中
reflect.SliceHeader的字段顺序和对齐已稳定，可放心使用 - 该指针仅在原切片生命周期内有效；切片被 GC 或重新切分后，指针可能悬空
用 unsafe.String 和 unsafe.Slice 避免手动转换
如果你只是想把 []byte 转成 string（或反之）而不拷贝，Go 1.20+ 提供了更安全的原语，完全绕过 reflect.SliceHeader 手动解析：
s := unsafe.String(&data[0], len(data)) // []byte → string b := unsafe.Slice(unsafe.StringData(s), len(s)) // string → []byte
这些函数内部已处理边界检查和内存布局细节，比手写 unsafe.Pointer 转换更可靠。
-
unsafe.StringData返回的是*byte，不是unsafe.Pointer，需再用unsafe.Slice包装成切片 - 它们不适用于任意切片类型（比如
[]int），仅限[]byte↔string - 仍需确保源数据不被提前释放或修改（例如不能对局部
[]byte转出的string长期持有，除非你控制了它的生命周期）
常见 panic 和竞态隐患
最典型的错误是忽略切片是否为空就调用 &slice[0]，导致运行时报 panic: runtime error: index out of range；另一个隐蔽问题是，在 goroutine 间共享通过 unsafe 获取的指针，但未加同步——因为 GC 不知道你在用这个指针，可能提前回收底层数组。
- 永远先判断
len(slice) > 0再用&slice[0]，或者统一走reflect.SliceHeader方案（它对空 slice 的Data字段返回 0，不会 panic） - 若需长期持有指针，考虑用
runtime.KeepAlive(slice)告诉 GC “这个切片还在被 unsafe 指针引用”，防止过早回收 - 在 cgo 场景中传指针给 C 函数时，务必用
C.CBytes或显式malloc+memmove，不要直接传unsafe.Pointer(hdr.Data)——C 侧无法感知 Go 的 GC 生命周期
真正难的不是怎么取到指针，而是确保它在整个使用过程中始终有效且不越界。每次写 unsafe 相关代码，都要问自己：这个指针的生命周期由谁管理？有没有其他 goroutine 在改它？GC 会不会在中间把它收走？
