Go 语言的垃圾回收器可能移动堆上对象，导致其内存地址改变；因此，将 Go 指针（*T）直接转换为 unsafe.Pointer 并传入 C 代码是不安全的——C 侧无法感知地址更新，也无法阻止对象被回收，从而引发崩溃或未定义行为。
go 语言的垃圾回收器可能移动堆上对象，导致其内存地址改变；因此，将 go 指针（*t）直接转换为 unsafe.pointer 并传入 c 代码是不安全的——c 侧无法感知地址更新，也无法阻止对象被回收，从而引发崩溃或未定义行为。
在 Go 与 C 交互（尤其是通过 cgo）时，一个关键限制是：*不能将指向 Go 分配内存的指针（特别是包含 Go 指针字段的结构体）作为 `void传递给 C 代码长期持有**。你遇到的runtime error: Go pointer to Go pointer正是 Go 运行时在调用C.go_register_cb(unsafe.Pointer(x))` 时动态检测到违规后触发的安全保护机制。
根本原因在于 Go 的并发标记-清除（或三色标记）垃圾收集器支持堆内存压缩与对象重定位（如在某些 GC 实现中启用的 compacting GC 或 future 的优化路径）。虽然当前 Go（1.22+）默认不主动压缩内存，但运行时保留了移动对象的能力，且所有 Go 指针（*T）均受 GC 管理：当对象被移动时，GC 会自动更新所有 Go 栈、寄存器及 Go 堆中的指针值。然而，unsafe.Pointer 转换为 uintptr 后即脱离 GC 管理，其值不会被更新，也不构成对象的根引用（root），因此：
- ✅
unsafe.Pointer(x)在 本次调用瞬间 是有效的； - ❌ 一旦
x所在对象被 GC 移动，uintptr值将失效； - ❌ 若
MyStruct内部含有其他 Go 指针字段（如*string,[]int,map[string]int），则unsafe.Pointer(x)本身即违反“Go 指针不得嵌套在 C 可见数据中”的规则——这正是运行时报错的直接原因。
正确做法：使用 runtime.Pinner（Go 1.21+）或手动固定对象
自 Go 1.21 起，推荐使用 runtime.Pinner 显式固定对象，防止其被 GC 移动，并确保 C 侧可安全持有指针：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
import (
"runtime"
"unsafe"
"C"
)
type MyStruct struct {
data int
// 注意：Pinner 仅保证对象不移动，不阻止回收！需额外保持 Go 侧引用
}
func (x *MyStruct) Start() {
// 1. 创建 pinner 并 pin 当前对象
pin := runtime.Pinner{}
pin.Pin(x) // x 现在被固定在内存中，地址不再变化
// 2. 将指针传给 C（注意：必须确保 pin 生命周期 >= C 使用期）
C.go_register_cb(unsafe.Pointer(x))
// 3. 在 C 不再需要该指针后（例如回调结束或显式注销时），Unpin
// （实际中建议将 pin 存为字段或通过 context 管理生命周期）
}
⚠️ 重要注意事项：
-
runtime.Pinner.Pin()仅防止对象移动，不阻止 GC 回收——你仍需在 Go 侧保持对该对象的有效引用（如将其存储在全局 map 或结构体字段中），否则对象可能被回收，造成悬垂指针。 - 若无法升级到 Go 1.21+，传统方案是使用
C.malloc在 C 堆分配内存，将 Go 数据复制过去，并用C.free清理；或通过reflect+unsafe构造纯 C 兼容结构体（不含任何 Go 指针）。 - 绝对避免：
uintptr(unsafe.Pointer(x))→C.uintptr_t→ C 侧存储；这是最危险的模式，既丢失 GC 跟踪，又失去地址稳定性。
总结
Go 指针的地址可能因垃圾回收而改变，这是语言设计为支持高效内存管理所做出的权衡。cgo 的严格检查并非过度约束，而是防止难以调试的内存错误。正确桥接 Go 与 C 的核心原则是：让 C 持有 C 分配的内存，或使用 runtime.Pinner 显式固定 Go 对象，并始终维持 Go 侧强引用。遵循此模式，即可安全实现高性能、稳定的跨语言回调机制。
