unsafe.Pointer是参与GC跟踪的真正指针，uintptr是GC无视的纯整数；指针运算必须在单个表达式内完成unsafe.Pointer→uintptr→unsafe.Pointer转换，否则GC可能回收对象导致panic。
unsafe.Pointer 是指针，uintptr 是整数
这是最根本的区分：Go 编译器和 GC 对两者完全区别对待。unsafe.Pointer 是真正的指针类型，参与 Go 的指针语义——GC 会跟踪它指向的对象，防止被提前回收；uintptr 则是纯整数（等价于 uint64 或 uint32），GC 完全无视它存的是不是地址。哪怕你把一个变量的地址转成 uintptr 存下来，稍后想转回去读，对象可能早已被回收，解引用时直接 panic: invalid memory address。
指针运算必须走 uintptr → unsafe.Pointer 这条链
Go 禁止普通指针算术（比如 p + 1），但允许通过 uintptr 实现偏移。关键在于：所有转换必须在**单个表达式内完成**，不能拆成多步赋值或跨函数传递。
- ✅ 安全写法：
*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s)) + unsafe.Offsetof(s.field))) - ❌ 危险写法：
u := uintptr(unsafe.Pointer(&s)); ...; *(*int)(unsafe.Pointer(u + offset))—— 中间变量u会让 GC 失去对&s的引用，极大概率 panic - ⚠️ 注意：
unsafe.Pointer本身不能加减，必须先转uintptr才能做偏移；反过来，uintptr也不能直接转成*T，必须经由unsafe.Pointer中转
常见误用场景：结构体字段访问与 slice 底层操作
这两类操作最容易暴露语义混淆问题：
- 访问未导出字段时，有人把
unsafe.Pointer(&s)存进全局变量或 struct 字段，后续再用——这等于把指针“降级”为整数并长期持有，GC 不认账 - 实现自定义 slice 操作（如跳过前 N 字节）时，用
uintptr计算新数据起始地址，但忘了新地址是否仍在原底层数组有效范围内；越界访问不报错，但行为未定义 -
unsafe.Sizeof、unsafe.Offsetof返回的都是uintptr，它们只描述布局，不提供内存生命周期保证
为什么不能跳过 unsafe.Pointer 直接 *T → uintptr → *U？
编译器强制要求中间必须经过 unsafe.Pointer，本质是插入一道类型安全检查闸门：
立即学习“go语言免费学习笔记（深入）”；
-
*T → uintptr不被允许（编译报错），因为这会绕过 GC 跟踪，且失去类型上下文 -
uintptr → *U也不被允许（编译报错），因为整数到指针的转换必须显式声明“我清楚这是地址，我要把它当指针用” - 只有
*T → unsafe.Pointer → uintptr → unsafe.Pointer → *U这条路径被语言明确支持，每一步都有语义含义：先剥离类型（但保留 GC 引用），再数值化，再重新绑定指针语义
真正难的不是语法怎么写，而是判断某块内存是否还在“活”的引用链里——一旦离开当前作用域或函数调用栈，uintptr 就只剩下一个数字，而那个数字对应的地址，可能已经归零。
