unsafe包是绕过编译检查的内存通行证，日常开发95%无需使用；强制转换必须经桥接类型（如*byte），切片转结构体需用&buf[0]而非&buf，读私有字段须用unsafe.Offsetof，uintptr不可持久化存储。
unsafe 包不是类型转换工具，而是绕过编译检查的“内存通行证”；95% 的日常开发完全不需要它，强行用只会引入静默崩溃或数据损坏。
为什么 (*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]
这是最典型的 panic 来源：把 slice 变量本身（三字段描述符）的地址当成底层数组地址用，结果覆写 data 指针，后续访问直接 panic: invalid memory address or nil pointer dereference。
- 错误：
t := (*Point)(unsafe.Pointer(&buf))→&buf指向的是 slice header，不是数据内存 - 正确：
t := (*Point)(unsafe.Pointer(&buf[0]))→ 确保指向真实分配的字节内存起始位置 - 前提条件：
buf长度必须 ≥ 目标结构体大小，否则越界读写
读私有字段必须用 unsafe.Offsetof，且 uintptr 不能存变量
字段偏移受对齐、填充、字段顺序影响，手算 0、8、16 看似快，但加个字段就全错；而把 unsafe.Pointer 转成 uintptr 后赋值给变量，等于主动告诉 GC “这个内存我不管了”，原对象可能被提前回收。
立即学习“go语言免费学习笔记（深入）”；
- 必须用：
unsafe.Offsetof(u.name)，而不是靠字段顺序猜或硬编码 - 危险写法：
addr := uintptr(unsafe.Pointer(&u)) + offset→addr是纯数值，GC 不跟踪 - 安全写法：
(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(&u)) + unsafe.Offsetof(u.name)))→uintptr仅用于中间计算，立刻转回unsafe.Pointer - 注意：未导出字段无法通过
reflect.Value.UnsafeAddr()获取地址（会 panic），只能靠首地址 + 偏移硬跳
对齐和解引用前必须确认内存是否可读、是否对齐
直接对 unsafe.Pointer 解引用或做算术运算会编译失败；转成具体类型指针后，若原始内存不满足该类型的对齐要求（比如从字节切片起始地址硬转 *int64），运行时可能 panic：misaligned 64-bit atomic operation。
-
unsafe.Pointer本身不能解引用，必须先转成*int32这类具体类型指针，再*(*int32)(p) - 结构体内存布局由编译器决定，不同 Go 版本或构建模式下可能微调，不能当契约依赖
- 用
go tool compile -S可看实际布局，但仅作验证，不可固化到逻辑中
真正容易被忽略的点是：uintptr 一旦脱离单表达式上下文（比如存入 map、全局变量、返回值），GC 就彻底丢失对其指向内存的追踪——这不是 bug，是设计使然，但后果往往是难以复现的静默内存损坏。
