不能直接把 *T 转成 uintptr，因为GC会移动堆对象而uintptr无GC可见性，导致悬垂指针；正确做法是先转unsafe.Pointer再转uintptr，并确保原始指针活跃或用runtime.KeepAlive。
为什么不能直接把 *T 转成 uintptr
Go 的垃圾回收器会移动堆上对象，而 uintptr 是纯数值、不带类型和 GC 可见性。一旦你把 *T 强转成 uintptr，GC 就不再认为这个地址还被引用——下次 GC 一动，原内存可能就被覆盖或复用，后续再用这个 uintptr 去取值，就是未定义行为（常见 panic：invalid memory address or nil pointer dereference，或者读到脏数据）。
正确做法是：只在「极短生命周期」内用 uintptr，且必须配合 unsafe.Pointer 中转，让 GC 知道指针还在被持有。
- ❌ 错误：
u := uintptr(&x)—— &x 返回*T，直接转uintptr断开了 GC 关联 - ✅ 正确：
u := uintptr(unsafe.Pointer(&x))—— 先转unsafe.Pointer，再转uintptr，中间这步让 GC 仍能追踪 - ⚠️ 注意：
unsafe.Pointer本身不能参与算术运算；想加偏移，必须先转uintptr，算完再转回unsafe.Pointer
uintptr + 偏移后怎么安全转回指针
底层结构体字段偏移、系统调用传地址、绕过反射限制等场景，常需要「地址 + 偏移 → 新指针」。关键不是算得对不对，而是整个链条不能让 GC 失去对原始对象的引用。
典型错误是：算出新 uintptr 后，直接 (*T)(unsafe.Pointer(u)) —— 如果原始对象在这之间被 GC 移走，就崩了。
立即学习“go语言免费学习笔记（深入）”；
- 必须确保原始指针（比如
&x）在整个运算过程中保持活跃（例如作为局部变量存在，没被编译器优化掉） - 推荐写法：
ptr := &x uptr := uintptr(unsafe.Pointer(ptr)) offset := unsafe.Offsetof(ptr.field) newPtr := (*int)(unsafe.Pointer(uptr + offset))
- 不要把
uptr存到全局变量或 long-lived 结构里；它只在当前函数栈帧内有效 - 如果涉及跨 goroutine 使用，必须用
runtime.KeepAlive(ptr)告诉编译器：这个ptr在此之后仍被需要
哪些场景真需要 uintptr，哪些只是错觉
多数所谓“底层操作”，其实有更安全的替代方案。滥用 uintptr 是 Go 中最难 debug 的崩溃来源之一。
- ✅ 合理场景：
syscall.Syscall传缓冲区地址、reflect实现中绕过类型检查、自定义内存池管理（如sync.Pool底层）、FFI 调用 C 函数时传递结构体首地址 - ❌ 过度设计：
mapkey 用uintptr存地址（应该用unsafe.Pointer或 ID）、手动实现 slice header（reflect.SliceHeader更稳）、仅为了“看起来快”而绕过 bounds check - ⚠️ 特别注意：
unsafe.Sizeof/Offsetof返回的是uintptr，但它们本身不触发 GC 风险；危险的是你拿这个值去构造新指针并长期持有
Go 1.22+ 的变化与兼容性提醒
Go 1.22 开始，编译器对 unsafe 相关代码做了更强的逃逸分析，部分过去“侥幸跑通”的 uintptr 操作会被直接拒绝（如在闭包中捕获并返回 uintptr 地址）。
- 现在
uintptr不再隐式允许转回unsafe.Pointer；必须显式写unsafe.Pointer(uintptr(...)) - 如果用了 cgo，要注意 C 代码生命周期必须严格长于对应的
uintptr使用期；Go 侧不能假设 C 分配的内存一直有效 - 交叉编译时，
unsafe.Sizeof和Offsetof结果可能因平台对齐差异而不同，别硬编码偏移值
真正难的不是算出那个数字，而是让整个引用链始终落在 GC 的视线里。只要漏掉一个 unsafe.Pointer 中转，或者少写一行 runtime.KeepAlive，问题就可能在压测三天后才爆发。
