Go 的垃圾回收器可能移动堆上对象的内存地址，因此 Go 指针（*T）的数值并非固定不变；若将 unsafe.Pointer 转为 uintptr 传入 C 代码，GC 无法追踪该引用，可能导致悬垂指针或运行时 panic。
go 的垃圾回收器可能移动堆上对象的内存地址，因此 go 指针（`*t`）的数值并非固定不变；若将 `unsafe.pointer` 转为 `uintptr` 传入 c 代码，gc 无法追踪该引用，可能导致悬垂指针或运行时 panic。
在 Go 与 C 交互（尤其是通过 cgo）时，一个关键但容易被忽视的约束是：不能将指向 Go 分配内存的指针（包括嵌套含 Go 指针的结构体）直接传递给 C 代码长期持有。你遇到的 runtime error: Go pointer to Go pointer 正是 Go 运行时对这一规则的动态检查结果——它并非编译期警告，而是在调用发生时主动拦截非法内存操作。
根本原因在于 Go 的并发标记清除式垃圾收集器（如当前默认的三色 GC）会压缩堆内存、移动对象以减少碎片。当对象被移动时，Go 运行时会自动更新所有 Go 原生指针（如 *MyStruct）的值，确保它们始终指向新地址。但这一机制仅作用于 Go 可见的指针类型，不适用于 uintptr 或 C 端持有的裸地址：
// ❌ 危险：转换为 uintptr 后，GC 失去追踪能力 cookie := uintptr(unsafe.Pointer(&x)) // x 是 Go 分配的 MyStruct 实例 C.go_register_cb(cookie) // C 保存此整数地址 —— GC 移动 x 后，该值即失效 // ✅ 安全：使用 runtime.KeepAlive 或显式生命周期管理 C.go_register_cb(unsafe.Pointer(&x)) runtime.KeepAlive(x) // 告知 GC：x 在此之后仍被使用（需放在函数末尾）
更推荐的实践是避免传递 Go 对象指针本身，转而使用以下任一方案：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
使用
C.malloc在 C 堆分配内存，将必要数据复制过去，并在 Go 中维护对应*C.struct_x的生命周期； -
借助
sync.Map或全局注册表，将 Go 对象存入 map，仅向 C 传递稳定 ID（如int或uintptr作为 map 键），回调时再查表还原； -
对简单结构体启用
//go:notinheap标签（需谨慎），使其永不被 GC 移动（仅限特定场景，且不适用于含指针字段的结构体）。
最后务必注意：unsafe.Pointer 本身是 Go 类型，可被 GC 追踪；但一旦转为 uintptr，它就退化为普通整数，彻底脱离 GC 管理。官方文档明确强调：“Even if a uintptr holds the address of some object, the garbage collector will not update that uintptr's value if the object moves, nor will that uintptr keep the object from being reclaimed.” —— 这正是你问题中现象的技术根源。
