uintptr不会被GC扫描，因其是无符号整数而非指针类型；而unsafe.Pointer会被GC识别并扫描所指向对象，二者转换会断开GC关联，误用导致野指针、崩溃或内存错误。
uintptr 会被 GC 当成普通整数，完全不扫描
Go 的垃圾回收器只扫描指针类型（*T、unsafe.Pointer），而 uintptr 是无符号整数类型，GC 对它视而不见。哪怕你用 uintptr 存了一个对象的地址，只要没有其他活的指针指向该对象，GC 就可能把它回收掉——然后你再用这个 uintptr 去访问，就是野指针。
常见错误现象：panic: runtime error: invalid memory address or nil pointer dereference 或更隐蔽的内存乱码、程序崩溃，尤其在 GC 触发后才暴露。
- 使用场景：仅适合极短生命周期的中间计算，比如在单次系统调用中传地址给 C 函数，且确保 C 不会异步保存或延迟使用该地址
- 不能跨函数返回
uintptr，也不能存入全局变量、切片、map 或结构体字段 - 若必须长期持有地址，请用
unsafe.Pointer并配合显式指针引用（例如让一个*T变量活着）
为什么 unsafe.Pointer 能被 GC 扫描，而 uintptr 不能
unsafe.Pointer 是 Go 中唯一能和指针互转的“合法”非类型化指针类型；编译器和运行时都把它当指针处理，GC 会顺着它扫描所指向的对象。但 uintptr 是纯数值，和 uint64 没区别——它只是碰巧能存地址而已。
参数差异很关键：unsafe.Pointer 和 *T 可以双向转换（需显式强制类型转换），而 uintptr 和 unsafe.Pointer 的互转是「有损」的：一旦转成 uintptr，就断开了与 GC 的关联。
立即学习“go语言免费学习笔记（深入）”；
-
unsafe.Pointer→uintptr：允许，但“脱钩”GC -
uintptr→unsafe.Pointer：语法允许，但此时 GC 完全不知道这个指针指向谁 - 真正安全的做法是：先确保有活跃的
*T指针存在，再用unsafe.Pointer转换，避免经过uintptr
典型踩坑：把 reflect.Value.UnsafeAddr() 结果转成 uintptr 后缓存
reflect.Value.UnsafeAddr() 返回的是 uintptr，不是 unsafe.Pointer。很多人直接把它存起来，以为拿到了对象地址就能长期用——其实这等于告诉 GC：“这个地址我不管了”。如果原对象是局部变量或临时分配的，下一次 GC 就可能回收它。
示例问题代码：
func bad() uintptr {
s := []int{1, 2, 3}
return reflect.ValueOf(&s).Elem().UnsafeAddr()
}
// 返回的 uintptr 指向已逃逸但无引用的底层数组，s 变量作用域结束，GC 可能立刻回收
- 正确做法：改用
reflect.ValueOf(&s).Elem().UnsafePointer()（注意函数名不同），再配合保持s的存活（如返回&s或延长其作用域） - 或者根本别缓存——每次需要时重新取，确保对象还活着
- 用
runtime.KeepAlive(s)可以延长局部变量生命周期，但仅对当前函数有效，不能解决跨函数传递问题
性能与兼容性：uintptr 转换本身不慢，但后果不可控
uintptr 运算（加减偏移、转回 unsafe.Pointer）几乎没有运行时开销，比反射快得多。但它带来的不确定性远超这点性能收益——尤其在 GC 策略变化（如 Go 1.22+ 的增量式 GC）、跨平台（GOOS=js 或 wasm 下行为更受限）或启用 -gcflags="-d=checkptr" 时，非法访问会直接 panic。
- Go 1.20+ 默认开启 checkptr 检查，用
uintptr访问未分配/已释放内存会触发fatal error: checkptr: unsafe pointer conversion - 交叉编译到 ARM64 或 WASM 时，地址对齐要求更严，
uintptr手动计算偏移容易越界 - 真正需要零拷贝或系统调用时，优先封装为局部、短生命周期操作，避免任何“持有地址等以后用”的思路
最常被忽略的一点：GC 不只看变量是否“还在栈上”，更看是否有从根可达的指针链。只要中间断了一环（比如本该用 unsafe.Pointer 却用了 uintptr），整个链就失效了——而这种失效往往不报错，只悄悄出问题。
