uintptr不会被GC扫描，其值修改不影响GC行为；真正风险是用它存储地址后原对象被回收，导致转为unsafe.Pointer解引用时崩溃。
uintptr 不会被 GC 扫描，改不改它都不影响 GC 行为
uintptr 本质是 uint64（在 64 位系统上），只是“碰巧能存地址”。go 的垃圾回收器只扫描指针类型——*t、unsafe.pointer、map、chan、interface{} 等含指针字段的复合类型。它完全忽略 uintptr 的值，既不会读取它，也不会因它而保留任何对象。
所以“被修改”不是风险点；真正风险是：你用 uintptr 存了一个地址，然后以为它“还有效”，结果 GC 已经把原对象回收了。
- GC 不会因
uintptr的存在而延长对象生命周期 -
uintptr被赋新值、被加减、被传参，对 GC 都无影响 - 崩溃通常发生在你拿这个
uintptr转回unsafe.Pointer后解引用时
为什么 uintptr + unsafe.Pointer 互转容易触发 GC 提前回收
关键在转换链是否原子。GC 的可达性分析发生在栈扫描瞬间，而编译器无法保证两行代码之间的执行间隙里不触发 GC。
错误写法：
u := uintptr(unsafe.Pointer(&x))<br>p := (*int)(unsafe.Pointer(u))中间变量
u 是纯整数，&x 对应的局部变量 x 若未逃逸，可能在第二行执行前就被 GC 回收。
- 必须写成单表达式：
(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&x)) + offset)) - 所有偏移计算（+4、+unsafe.Offsetof(s.b)）必须和转换一起完成，不能拆开
- 哪怕只加一个
fmt.Println("debug")在中间，也可能插入 GC 安全点
哪些场景会让 uintptr 指向的内存“突然失效”
不是内存被“修改”，而是它所指向的对象被 GC 回收后，那块地址变成野区。后续访问即崩溃或静默错乱。
- 函数返回
reflect.Value.UnsafeAddr()结果（它返回uintptr，不是unsafe.Pointer） - 把
uintptr存入map、[]uintptr或结构体字段，试图“缓存地址” - 在
goroutine中异步使用由主 goroutine 生成的uintptr - 用
uintptr初始化reflect.SliceHeader.Data，但底层数组是局部变量（如[1024]byte{}）
这些操作都等于主动切断 GC 与目标对象的关联，且无任何运行时检查提醒你。
替代方案：什么时候该用 unsafe.Pointer 而不是 uintptr
只要你需要“让 GC 知道这个地址指向谁”，就必须用 unsafe.Pointer，并确保有活跃的 *T 变量持有它。
- 用
reflect.Value.UnsafePointer()替代UnsafeAddr()（注意函数名差一个词） - 构造 slice 优先用
unsafe.Slice((*T)(ptr), len)（Go 1.17+），ptr必须是unsafe.Pointer - 跨函数传递地址时，传
*T或unsafe.Pointer，而非uintptr - 若必须算偏移，用
unsafe.Add(ptr, offset)（Go 1.19+），它接受unsafe.Pointer并返回unsafe.Pointer，全程不经过uintptr
最常被忽略的一点：uintptr 的“安全窗口”是以表达式为单位的，不是以函数或作用域为单位。哪怕你在同一行里写了十个操作，只要没中间变量，GC 就来不及插手——但一旦落地为变量，就已出局。
