unsafe.Pointer 转换 struct 时字段对齐不一致会直接崩溃，因内存布局不兼容导致读越界或未初始化内存；uintptr 中转指针可能触发 GC 误回收造成悬垂指针；[]byte 转 *C.char 忘记保持底层数组存活会导致 C 端使用已释放内存。
unsafe.Pointer 转换 struct 时字段对齐不一致会直接崩溃
Go 的 unsafe.Pointer 允许绕过类型系统做内存重解释，但前提是源和目标类型的内存布局完全兼容。常见错误是把一个 struct{a uint32; b uint8} 强转成 struct{a uint8; b uint32} —— 字段顺序或大小一变，unsafe.Pointer 就读错偏移，结果不是值不对，而是读到未初始化内存或越界地址，运行时 panic 或静默数据污染。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
unsafe.Offsetof和unsafe.Sizeof显式比对两个 struct 的每个字段偏移和总大小，不能只看字段名和类型是否“看起来一样” - 优先用
encoding/binary+bytes.Buffer做字节序列化转换，安全且可测 - 如果必须用
unsafe，确保两个 struct 都加了//go:notinheap注释，并用go vet -unsafeptr扫描潜在越界
uintptr 临时存指针再转回 unsafe.Pointer 可能触发 GC 误回收
这是最隐蔽的坑：把 unsafe.Pointer 转成 uintptr 后，Go 的 GC 就“看不见”这个指针了。如果中间有函数调用、循环或 goroutine 切换，原对象可能被回收，再转回 unsafe.Pointer 就成了悬垂指针，后续读写大概率 segfault。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
uintptr只能作为中间计算值，且必须在**单条表达式内**完成“Pointer → uintptr → Pointer”链，不能拆成两行赋值 - 错误写法：
u := uintptr(unsafe.Pointer(&x)); ...; p := (*int)(unsafe.Pointer(u))—— 中间省略号可能触发 GC - 正确写法：
p := (*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&x)) + 4))（一行内完成）
将 []byte 转 *C.char 时忘记保持底层数组存活
C 函数常要求传入的 *C.char 在调用期间有效，但 Go 的 []byte 转 *C.char 通常靠 (*C.char)(unsafe.Pointer(&s[0])) 实现。问题在于：如果 s 是局部切片，函数返回后底层数组可能被 GC 回收，而 C 代码还在用那块内存。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
C.CString分配 C 堆内存并手动C.free，虽然多一次拷贝但可控 - 若坚持零拷贝，必须确保
[]byte的底层数组生命周期 ≥ C 函数执行期，例如把切片定义为包级变量，或用runtime.KeepAlive(s)在 C 调用后显式引用 - 注意
unsafe.Slice（Go 1.17+）不能用于跨语言场景，它不保证与 C 内存模型兼容
用 unsafe.Alignof 判断结构体能否 memcpy 会漏掉编译器填充差异
unsafe.Alignof 返回的是类型对齐要求，不是实际填充位置。两个 struct 对齐值相同，不代表它们字段之间没插入不同数量的 padding 字节。比如 struct{a int8; b int64} 和 struct{a int8; _ [7]byte; b int64} 对齐都是 8，但前者总大小是 16，后者是 24 —— 直接 memcpy 会错位。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
unsafe.Offsetof(t.b) - unsafe.Offsetof(t.a)检查字段间距，而非只看Alignof - 生成代码时用
go tool compile -S查看汇编输出里的MOVQ偏移，确认字段真实位置 - 涉及 C 交互的 struct，务必加
//go:packed并用#pragma pack(1)对齐 C 端，否则跨平台必出问题
真正危险的从来不是 unsafe 本身，而是你以为自己控制了内存，其实只是暂时没被 GC 或硬件异常抓到。每次写 unsafe.Pointer，都要问一句：这个地址，下一行代码执行时还合法吗？
