unsafe.Pointer不是万能转换器，仅是绕过编译检查的通行证；必须经桥接类型转换，切片转结构体须用&slice[0]，字段偏移须用unsafe.Offsetof，95%场景无需unsafe。
不能把 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: invalid memory address or nil pointer dereference。
- 错误：
t := (*Point)(unsafe.Pointer(&buf))→&buf指向的是 slice header，不是数据内存 - 正确：
t := (*Point)(unsafe.Pointer(&buf[0]))→ 确保指向真实分配的字节内存起始位置 - 前提条件：slice 长度必须 ≥ 目标结构体大小，否则越界读写
读私有字段时，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？哪些其实不该碰
95% 的所谓“需要强制转换”的需求，本质是没找对抽象层级。unsafe 存在的意义很窄：对接系统调用、实现零拷贝序列化、构建高性能内存池——不是为了替代 interface{} 或绕开类型断言。
- 合理使用：
syscall.Read(fd, buf)中传unsafe.Pointer(&buf[0])（前提是len(buf) > 0） - 合理使用：
*(*uint32)(unsafe.Pointer(&data[0]))解析网络包头（需确认字节序和长度） - 应避免：把 struct 当字节数组发网络 → 用
encoding/binary.Write更安全 - 应避免：根据字段名动态赋值 → 用
reflect.StructField，而非硬算偏移
真正难的从来不是怎么写那行 (*T)(unsafe.Pointer(...))，而是判断要不要写、写完后内存是否还活着、字段偏移有没有被编译器悄悄调整——这些没法靠编译器提醒，得靠你盯着 unsafe.Sizeof、unsafe.Alignof 和 go tool compile -S 输出来验证。
