Go 语言中，指向 Go 分配内存的指针在运行时可能因垃圾回收器的内存整理（如紧凑型 GC）而发生地址变更；因此，将 *T 类型的 Go 指针直接转为 unsafe.Pointer 并长期交由 C 代码持有是不安全的——C 无法感知或更新该地址，极易导致悬空指针或崩溃。
go 语言中，指向 go 分配内存的指针在运行时可能因垃圾回收器的内存整理（如紧凑型 gc）而发生地址变更；因此，将 *t 类型的 go 指针直接转为 unsafe.pointer 并长期交由 c 代码持有是不安全的——c 无法感知或更新该地址，极易导致悬空指针或崩溃。
在 Go 与 C 交互（尤其是通过 cgo）时，一个关键约束是：*不能将 Go 分配的对象指针（T）直接传递给 C，并让 C 长期持有其地址**。你遇到的 runtime error: Go pointer to Go pointer 正是 Go 运行时对这一规则的动态检查结果——它并非编译时报错，而是在调用时检测到非法的指针跨边界使用后 panic。
根本原因在于 Go 的垃圾收集器（自 Go 1.5 起采用并发、三色标记-清除+紧凑式回收）会移动对象以减少内存碎片。当对象被移动时，Go 运行时会自动更新所有 Go 堆上的指针引用（例如栈、全局变量、其他 Go 对象中的字段），但 *unsafe.Pointer 转换后的地址若被存储在 C 内存中（如 void cookie），则完全脱离 GC 管理范围，不会被更新**。此时，C 回调中再用该地址解引用，就可能访问已释放/重用的内存，引发未定义行为。
例如，以下写法是危险的：
func (x *MyStruct) Start() {
C.go_register_cb(unsafe.Pointer(x)) // ❌ 危险：x 是 Go 堆分配对象，地址可能被 GC 移动
}
✅ 安全替代方案有三种常见模式：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
使用
runtime.Pinner（Go 1.21+ 推荐）
显式固定对象内存位置，防止 GC 移动：import "runtime" type MyStruct struct { /* ... */ } func (x *MyStruct) Start() { runtime.Pinner{}.Pin(x) // 保持 x 在内存中不动 defer runtime.Pinner{}.Unpin(x) C.go_register_cb(unsafe.Pointer(x)) } -
分配在 C 堆上（推荐兼容旧版本）
用C.Cmalloc分配内存，手动拷贝数据，确保生命周期由 C 管理：func (x *MyStruct) Start() { cPtr := C.Cmalloc(C.size_t(unsafe.Sizeof(MyStruct{}))) if cPtr == nil { panic("malloc failed") } // 拷贝数据到 C 内存 *(*MyStruct)(cPtr) = *x C.go_register_cb(cPtr) } // 注意：需在适当时候调用 C.free(cPtr) -
使用全局 map + 整数 ID（最常用且安全）
将 Go 对象存入sync.Map，传给 C 的是整数 ID，回调时查表还原：var handles sync.Map // map[uint64]*MyStruct var handleID uint64 func (x *MyStruct) Start() { id := atomic.AddUint64(&handleID, 1) handles.Store(id, x) C.go_register_cb(unsafe.Pointer(uintptr(id))) // 传 uintptr，非指针 } //export callGo func callGo(ptr unsafe.Pointer) { id := uint64(uintptr(ptr)) if x, ok := handles.Load(id); ok { x.(*MyStruct).doSomething() } }
⚠️ 注意事项：
-
uintptr本身不是指针类型，GC 不会追踪它；仅当它临时用于地址计算并立即转回unsafe.Pointer（如(*T)(unsafe.Pointer(uintptr))）时才可安全使用，且必须确保整个表达式在单个 GC 周期内完成； - 绝对避免将
*T→unsafe.Pointer→uintptr→ 存储 → 后续再转回unsafe.Pointer，这是典型错误模式； - 所有通过 cgo 传入 C 的指针，若需长期有效，必须明确其内存归属（C 分配 or Go 固定），不可依赖 Go 堆的默认生命周期。
总结：Go 指针地址确实会因 GC 移动而改变，这是设计使然，而非 bug。正确做法是主动管理跨语言内存生命周期——要么固定（Pinner），要么移交（C 分配），要么间接化（ID 映射）。遵循这些原则，才能写出健壮、可维护的 cgo 代码。
