因为GC只追踪显式指针类型，uintptr中转会中断指针追踪，导致变量被提前回收；必须用原子表达式(*int)(unsafe.Pointer(&x))，不可拆分为uintptr变量。
为什么 unsafe.Pointer 不能直接转 *int 而要过 uintptr 中转
因为 Go 的垃圾回收器（GC）在栈扫描和指针追踪时，只识别「显式指针类型」——*T、chan T、map[T]U 等。而 unsafe.Pointer 虽是合法指针类型，一旦被转换成 uintptr，就彻底变成一个纯整数，GC 会完全忽略它指向的内存。
但问题出在「中转时机」：如果你写 *(*int)(unsafe.Pointer(&x))，Go 编译器能识别这是指针解引用，会确保 &x 对应的变量不被提前回收；可一旦你拆成两步：u := uintptr(unsafe.Pointer(&x)); p := (*int)(unsafe.Pointer(u))，中间的 u 是 uintptr，GC 可能在第二步执行前就把 x 给回收了（尤其在逃逸分析判定 x 不逃逸时）。
- 正确写法必须是原子表达式：
(*int)(unsafe.Pointer(&x))，不能拆开 - 所有涉及
uintptr的算术（比如加偏移）后，必须立刻转回unsafe.Pointer，且该行内完成后续转换，不能存为变量 - 常见翻车场景：循环里反复用
uintptr存地址、在 defer 或 goroutine 里延迟使用中转后的指针
unsafe.Offsetof 和 unsafe.Sizeof 在 struct 嵌套时为什么结果不符合直觉
Go 的 struct 内存布局受对齐规则约束，不是简单字段拼接。编译器会在字段间插入填充字节（padding），以满足每个字段自身的对齐要求（通常是自身大小的幂次，如 int64 要求 8 字节对齐）。
比如 struct{ a byte; b int64 }，unsafe.Offsetof(s.b) 返回的不是 1，而是 8——因为 b 必须从 8 字节边界开始，前面插了 7 字节 padding。
立即学习“go语言免费学习笔记（深入）”；
- 永远用
unsafe.Offsetof算偏移，别手算；字段顺序改变可能让 padding 分布突变 -
unsafe.Sizeof返回的是整个 struct 占用空间，包含末尾 padding，不一定等于各字段Sizeof之和 - 跨平台风险：不同 GOARCH（如
arm64vsamd64）对齐策略可能不同，unsafe计算结果不可移植
用 unsafe.Slice 替代 reflect.SliceHeader 为什么更安全
Go 1.17 引入 unsafe.Slice，本质是把过去靠 reflect.SliceHeader + unsafe.Pointer 手动构造 slice 的危险模式，封装成一个受控函数。它内部做了两项关键检查：参数合法性校验（如长度不能为负）、以及确保底层数组未被 GC 回收（通过保持原始指针活跃）。
而老写法：sh := &reflect.SliceHeader{Data: uintptr(unsafe.Pointer(&arr[0])), Len: n, Cap: n}; s := *(*[]byte)(unsafe.Pointer(sh))，存在两个硬伤：一是 sh 是局部变量，其生命周期结束即失效；二是 Go 1.20+ 已禁止将 reflect.SliceHeader 地址转为 slice 类型，直接 panic。
- 必须用
unsafe.Slice(ptr, len)，其中ptr必须指向已分配内存（如数组首地址、C.malloc返回值） - 不能对字符串底层用
unsafe.Slice(unsafe.StringData(s), len)—— 字符串数据是只读的，写入会 crash - 如果原内存来自
C.malloc，记得配对C.free；若来自 Go 数组，则无需手动释放，但需确保数组本身不被提前回收（比如不能是函数栈上临时数组）
CGO 交互中绕过 Go 内存管理的典型陷阱
当用 unsafe.Pointer 把 Go 切片传给 C 函数时，很多人忽略一点：Go runtime 不知道 C 侧会持有多久这个指针。如果 C 函数异步回调或长期缓存该指针，而 Go 侧切片已超出作用域，对应内存可能被复用或覆盖。
这不是 unsafe 的错，而是 Go 和 C 之间所有权边界没划清。
- 必须用
C.CBytes或C.calloc分配内存，并手动管理生命周期；传给 C 前用C.GoBytes复制一份，避免暴露 Go 堆内存 - 若必须传 Go 内存（如高性能零拷贝场景），得用
runtime.KeepAlive延长原变量生命周期，例如：defer runtime.KeepAlive(slice)放在 C 调用之后 - 绝对不要把
string直接转*C.char后长期持有——C.CString才是正确分配方式，且必须C.free
Unsafe 包本身没 bug，所有崩溃都源于对「谁负责这块内存」的误判。最常被忽略的，是那些看似无害的中间变量：一个 uintptr、一次多余的 defer、一段没 KeepAlive 的调用——它们不会报错，只会在某个特定 GC 周期突然失效。
