unsafe.Pointer 是绕过编译检查的“通行证”，非类型转换器；必须经 byte 或 uintptr 桥接才能转目标指针，切片转结构体须用 &slice[0] 而非 &slice，uintptr 会脱离 GC 跟踪，所有转换需在单表达式内完成。
unsafe.Pointer 不是类型转换器，它是绕过编译检查的“通行证”；用错一步，轻则读出垃圾值，重则 panic 或静默内存损坏。
为什么 (*int)(p) 会编译失败？必须走中间类型桥接
Go 编译器强制要求：从 unsafe.Pointer 转目标指针类型时，不能直接转，必须经过一个编译器认可的“桥接类型”，比如 *byte 或 *uintptr。这不是风格问题，是类型安全硬约束。
- 错误写法：
(*int)(p)（其中p是unsafe.Pointer）→ 报错cannot convert p (type unsafe.Pointer) to type *int - 正确写法：
(*int)(unsafe.Pointer(&x))——注意unsafe.Pointer必须是最内层转换结果 - 常见误写：
*(int)(unsafe.Pointer(&x))→ 试图把指针当整数解引用，编译失败
切片转结构体时，别取 &slice，要取 &slice[0]
这是最典型的崩溃源头：把 slice 变量本身（三字段描述符）的地址当成底层数组地址用，结果覆写 data 指针，后续访问直接 panic。
- 错误：
t := (*Point)(unsafe.Pointer(&buf))→&buf指向的是slice header，不是数据内存 - 正确：
t := (*Point)(unsafe.Pointer(&buf[0]))→ 确保指向真实分配的字节内存起始位置 - 前提条件：
buf长度必须 ≥ 目标结构体大小，否则越界读写 - Go 1.17+ 更推荐用
unsafe.Slice替代手算地址，语义清晰且 debug 模式下有边界检查
uintptr 不是“轻量版指针”，它是 GC 安全的断点
uintptr 是纯数值，GC 不追踪它；一旦转成 uintptr，就等于主动告诉 GC “这个内存我不管了”。原对象若无其他强引用，可能被提前回收。
- 危险写法：
u := uintptr(unsafe.Pointer(&x)); time.Sleep(time.Second); *(*int)(unsafe.Pointer(u)) = 42→ 中间隔着函数调用，&x可能已被回收 - 安全写法：
(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&x)) + unsafe.Offsetof(x.field)))→ 所有转换在单条表达式内完成，无变量存储、无函数调用 - 若需跨函数传递，必须保留原始 Go 指针（如传入结构体指针并作为返回值），或在作用域末尾加
runtime.KeepAlive(x) - 任何
fmt.Println、log.Print或 goroutine 切换都可能打断安全链
访问私有字段或系统调用时，偏移和生命周期必须双重校验
结构体字段偏移受对齐、填充、字段顺序影响，手算 0/8/16 看似快，但加个字段就全错；而 uintptr 存变量等于放弃 GC 跟踪。
- 必须用：
unsafe.Offsetof(u.name)，而不是靠字段顺序猜或硬编码 - 系统调用中传缓冲区地址，必须来自
unsafe.Pointer(&slice[0])，不能来自reflect.Value.UnsafeAddr()（可能指向栈上临时值） - 传入的
slice必须保证生命周期覆盖整个 syscall 过程；若异步返回（如某些ioctl），需额外同步机制 - 构造
reflect.SliceHeader时，Data字段必须是uintptr(unsafe.Pointer(&s[0]))，且s必须是 heap 分配（如make([]byte, n)）
真正危险的从来不是 unsafe.Pointer 本身，而是它暴露出来的两个事实：内存布局不可靠，GC 生命周期不可见。所有“看起来能跑通”的写法，只要没守住原子表达式、没校验偏移、没管住生命周期，就只是还没触发 GC 或还没碰到对齐变化而已。
