答案：导出函数返回Go分配指针会触发panic，因C无法感知Go栈伸缩与GC移动内存，运行时强制拦截以避免未定义行为；正确做法是让C分配内存、返回ID查表，或严格约定C立即释放。
为什么导出函数不能返回 Go 分配的指针
Go 语言运行时会直接 panic，错误信息是 cgo result has Go pointer。这不是警告，是硬性拦截——只要导出函数（带 //export 注释）返回值类型为 *C.char、*C.int 或任何指向 Go 内存的指针，程序启动或首次调用时就会崩溃。
根本原因在于：C 侧拿到指针后可能长期持有、异步使用，而 Go 的栈会伸缩、GC 会移动内存，C 无法感知这些变化。运行时宁可提前终止也不让未定义行为发生。
- 错误写法：
func ExportGetData() *C.char { return C.CString("data") }→ 必 panic - 安全替代方案一：让 C 分配 buffer，Go 填充内容（如
C.fillBuffer(buf, size)） - 安全替代方案二：返回整数 ID，C 通过另一个导出函数查表（如
ExportGetStrByID(id int) *C.char配合内部 map + sync.Pool 管理生命周期） - 若必须返回字符串且 C 侧承诺立即使用+释放，可用
C.CString+ 文档强约定，但无类型保障，不推荐用于关键路径
C 函数接收 Go 指针数组时 panic 的真实原因
报错 cgo argument has Go pointer to Go pointer 不是因为“传了指针”，而是因为 Go 运行时无法追踪嵌套指针结构的生命周期。例如 []*C.int 或 []C.pInt（其中 C.pInt = *C.int），底层是 Go 切片包含 Go 指针，再取 &slice[0] 就构成“Go 指针指向 Go 指针”，触发安全检查。
这种结构让 GC 无法判断 C 是否还在引用 slice 元素，也不敢回收，最终只能拒绝调用。
立即学习“go语言免费学习笔记（深入）”；
- 禁止写法：
ps := []*C.int{&x, &y}; C.processPtrs((*C.pInt)(unsafe.Pointer(&ps[0])), C.int(len(ps))) - 合规做法：C 端分配连续内存块，Go 只写入原始指针值。
ptrs := C.malloc(C.size_t(n * intSize)); defer C.free(ptrs); for i, p := range ps { *(*(*C.int)(unsafe.Pointer(uintptr(ptrs) + uintptr(i)*intSize))) = *p } - 更稳妥方式：改用单指针 + 长度参数，或封装为 C 结构体（字段为
void**+size_t），由 C 完全掌控内存布局
如何用 GODEBUG=cgocheck=2 发现指针越界问题
GODEBUG=cgocheck=2 是运行时强制校验模式，会在每次 C.CString、C.GoBytes、unsafe.Pointer 转换时做边界检查。一旦 Go 字符串已释放、切片已超出底层数组范围，或指针指向栈上临时变量，它会立刻 panic，并明确指出哪行代码越界。
它不是性能工具，而是开发/测试阶段的“安全探针”。线上禁用（默认是 1，只检查跨 goroutine 传递），但 CI 或本地调试必须开启。
- 启用方式：
GODEBUG=cgocheck=2 go run main.go或go test -gcflags="-gcsc" -run=TestCgo - 典型报错：
panic: cgo argument has Go pointer to Go pointer (code=2)或invalid memory address or nil pointer dereference前会附带具体行号和变量名 - 注意：它不检测 C 堆泄漏，只管 Go 内存是否被合法、稳定地暴露给 C；泄漏仍需靠
pprof和runtime.ReadMemStats观察HeapSys - HeapInuse差值
grep 扫描无法替代人工核对的三个盲区
全项目 grep -r "C\.CString\|C\.CBytes\|C\.malloc" . 只能定位分配点，但以下情况 grep 完全失效：
- error early return 路径遗漏
defer C.free：比如if err != nil { return err }在defer之后，实际不会执行 - C 函数内部缓存指针：如图像库接收
C.CBytes(buf)后保存为全局 buffer，Go 侧 free 了但 C 仍在用 → 表面无泄漏，实为 use-after-free - 第三方库封装的 CGO 分配：RobotGo 的
CaptureScreen返回CBitmap，必须配对FreeBitmap，但CBitmap不含C.前缀，grep 找不到
真正可靠的检查必须结合：静态扫描（如 go-critic 插件）、压测中观察 runtime.MemStats.HeapSys 单向增长趋势、以及对每个 CGO 调用点手动画出“分配→使用→释放”闭环。漏掉任意一环，泄漏就藏在那儿不动声色。
