必须用 unsafe.pointer 而不是类型断言，当你需绕过类型系统做底层内存视图转换，如 []byte 传 c 函数或零拷贝 string/[]byte 互转；因类型断言和 reflect 会复制或 panic，且 go 禁止直接取切片底层数组地址。
什么时候必须用 unsafe.Pointer 而不是类型断言
当你需要绕过 Go 的类型系统做底层内存视图转换时，unsafe.Pointer 不是“可选技巧”，而是唯一合法出口。比如从 []byte 直接拿到底层数据地址传给 C 函数，或实现零拷贝的 string 到 []byte 互转——此时 interface{} 断言或 reflect 都会触发复制或 panic。
常见错误现象：cannot convert []byte to *byte 或 invalid operation: cannot convert slice to pointer；本质是 Go 类型系统阻止你直接触碰底层数组头。
- 必须先用
unsafe.Slice（Go 1.21+）或reflect.SliceHeader+unsafe.Pointer拆解切片结构 - 永远不要对已逃逸到堆上的局部切片直接取
&slice[0]后转unsafe.Pointer——如果切片后续被 GC 收走，指针就悬空 - Go 1.20 之前常用
(*[1 这类写法，但它是未定义行为（UB），1.21 后应改用 <code>unsafe.Slice
unsafe.Pointer 转换 string 和 []byte 的安全边界
这个转换高频但危险：它不分配新内存，但会共享底层字节。问题不在转换本身，而在生命周期管理。
使用场景：HTTP body 解析、序列化反序列化中间层、高性能日志拼接。
立即学习“go语言免费学习笔记（深入）”；
-
string是只读的，所以从[]byte→string后，若原切片被修改，字符串内容可能意外变化（虽不推荐改，但语言不禁止） - 从
string→[]byte后，若对结果切片追加（append），可能触发底层数组扩容，导致新旧视图指向不同内存 - Go 1.20+ 推荐用
unsafe.String和unsafe.Slice替代手写reflect.StringHeader结构体赋值，前者做了基本合法性检查（如非 nil、长度非负）
示例（Go 1.21+）：
bs := []byte("hello")
s := unsafe.String(unsafe.SliceData(bs), len(bs)) // 安全转 string
bs2 := unsafe.Slice(unsafe.StringData(s), len(s)) // 安全转回 []byte
和 Cgo 交互时 unsafe.Pointer 的生命周期陷阱
最常踩的坑不是转换错，而是“传进 C 函数的指针，Go 忘了它还在用”。C 函数如果把指针存起来异步回调，而 Go 端变量早已超出作用域，就会 crash。
常见错误现象：unexpected fault address、signal SIGSEGV、或者 C 回调里读到乱码。
- 所有传给 C 的
unsafe.Pointer，背后数据必须显式保证存活——要么分配在堆上（如new或make），要么用runtime.KeepAlive延长栈变量生命周期 - 别依赖
defer C.free就万事大吉：如果 C 层持有指针时间 > defer 执行时机，照样悬空 - 用
C.CBytes分配内存时，记得手动C.free；用unsafe.SliceData获取已有 Go 内存地址时，绝不能让 C 层 free 它
为什么 unsafe.Pointer 不能直接和普通指针互相转换
因为 Go 编译器需要明确知道指针是否参与垃圾回收扫描。*T 是“可寻址、可追踪”的安全指针；unsafe.Pointer 是“黑盒地址”，编译器不会为它扫描所指内存，也就无法阻止 GC 提前回收。
所以你不能写 (*int)(unsafe.Pointer(&x)) 这种表达式——必须经过一次“中转”：
- 正确链路是：
unsafe.Pointer→uintptr→ 再转回*T（注意：两次转换必须在同一表达式里，否则uintptr可能被 GC 当作普通整数忽略） - 错误写法：
p := uintptr(unsafe.Pointer(&x)); ...; y := (*int)(unsafe.Pointer(p))—— 中间uintptr变量会让 GC 失去对&x的引用跟踪 - 实际项目里，这类转换几乎只出现在极底层（如自定义内存池、协程栈切换），日常业务代码应完全规避
真正难的从来不是怎么写那几行转换代码，而是确认整个内存生命周期里，没有任何一个环节被 GC 或栈帧销毁悄悄截断。
