在 CGO 交互中，若 Go 函数内部使用 new、make 或类似方式分配内存（如 *C.val），并将该指针写入 C 结构体字段，该内存由 Go 运行时管理，只要 Go 侧无强引用，最终会被垃圾回收器自动释放。
在 cgo 交互中，若 go 函数内部使用 `new`、`make` 或类似方式分配内存（如 `*c.val`），并将该指针写入 c 结构体字段，该内存由 go 运行时管理，只要 go 侧无强引用，最终会被垃圾回收器自动释放。
在您描述的场景中，Go 函数 go_func 内部通过 var v C.val = createValues() 创建了一个栈上值（注意：这本身不分配堆内存），但关键在于后续语句 C.set_val_in_array(varr, *v, C.size_t(0)) 和 c.values = varr —— 此处 varr 必须是由 Go 分配的堆内存指针（例如通过 C.Cmalloc、new(C.val) 或 (*C.val)(C.malloc(C.size_t(unsafe.Sizeof(C.val{})))) 等方式获得），否则 c.values 将指向无效或已释放的栈地址，引发未定义行为。
✅ 正确做法（推荐）：
在 Go 中使用 C.Cmalloc 分配内存，并明确告知 Go 运行时该内存需手动管理；或改用 Go 原生切片 + C.GoBytes/C.CBytes 配合 unsafe.Slice 安全桥接：
// 推荐：用 Go 分配，转为 C 兼容指针（内存受 GC 管理）
func go_func(c *C.c_struct) {
const n = 10
vals := make([]C.val, n) // Go 堆分配，GC 可见
for i := range vals {
vals[i] = createValues()
}
// 转为 C 指针（不转移所有权，Go 仍持有引用）
c.values = (*C.val)(unsafe.Pointer(&vals[0]))
c.values_cnt = (*C.size_t)(C.Cmalloc(C.size_t(unsafe.Sizeof(C.size_t(0)))))
*c.values_cnt = C.size_t(n)
// ⚠️ 注意：必须在 Go 侧保留对 vals 的引用！
// 否则 GC 可能在函数返回后立即回收 vals → c.values 成悬垂指针
// 解决方案：将 vals 存入全局 map 或 sync.Pool，或改用 C.Cmalloc
}
❌ 危险模式（如原代码所示）：
var varr *C.val var v C.val = createValues() C.set_val_in_array(varr, *v, 0) // varr 未初始化！此调用未定义 c.values = varr // 写入随机地址 → 严重安全隐患
该写法存在双重问题：varr 未初始化即被使用，且未建立 Go 对底层内存的任何引用，导致 GC 无法感知其存活状态。
? 核心原则：
-
Go 分配的内存（
new,make, slice backing array）默认受 GC 管理，但前提是 Go 运行时能追踪到该内存的活跃引用；一旦仅通过c.values持有指针而 Go 侧无变量引用，GC 会将其回收 → C 侧访问即崩溃。 -
C 分配的内存（
C.malloc,C.Cmalloc）不受 GC 管理，必须显式调用C.free，且需确保在 C 侧使用完毕后由 C 或 Go（通过导出函数）释放。 -
跨语言生命周期必须显式对齐：推荐策略是“谁分配，谁释放”，或统一由 Go 管理（配合
runtime.KeepAlive或闭包持有引用）。
✅ 最佳实践总结：
- 若数据生命周期由 C 控制，优先在 C 侧分配（
malloc），Go 仅读写； - 若由 Go 控制，使用
C.Cbytes+unsafe.Slice构造[]C.val，并通过runtime.KeepAlive(vals)延长引用至 C 使用结束； - 避免裸指针传递无引用跟踪的 Go 内存；
- 所有 CGO 内存操作务必配合
unsafe包规范和//go:cgo_unsafe_import_dynamic（如需）进行静态检查。
遵循以上原则，即可兼顾安全性与性能，避免悬垂指针与内存泄漏。
