cgo内存泄漏源于c堆内存未手动释放，因go gc无法管理c.malloc/c.cstring/c.cbytes分配的内存；必须配对使用c.free，且需defer保障、工具扫描与压测验证。
cgo 内存泄漏不是 gc 能自动回收的类型，不手动释放就永远留着——c.cstring、c.cbytes、c.malloc 分配的内存，go 的垃圾回收器完全看不见。
为什么 C.CString 不配 C.free 就会泄漏
因为 C.CString 底层调用的是 C 的 malloc，分配在 C 堆上；而 Go 的 GC 只管理 Go 堆和栈，对 C 堆上的内存一无所知。漏掉一次 C.free(unsafe.Pointer(cs))，那一块内存就再也回不来了。
- 常见错误模式：
cs := C.CString(s); someCFunc(cs)，没defer C.free - 高并发下几秒内就能涨几十 MB（实测从 7MB 涨到 20+MB）
- 即使函数很快返回，只要没 free，内存就持续累积
- 注意：
C.free(nil)是安全的，可省去判空，但不能省略调用
C.CBytes 和自定义 C 分配必须显式释放
C.CBytes 同样走 malloc，和 C.CString 一样需要配对 C.free。更隐蔽的是自己用 C.malloc 或 C.calloc 分配的内存，比如对接图像处理、音视频编解码库时常见。
-
data := C.CBytes(buf)→ 必须defer C.free(data) -
ptr := C.malloc(C.size_t(n))→ 必须defer C.free(ptr) - 切忌用
unsafe.Slice或unsafe.SliceHeader绕过C.CBytes，那样失去类型提示，更容易漏 free - 如果 C 函数要求长期持有该指针（如注册回调缓冲区），必须用 ID 映射 + 引用计数，不能直接传 Go 切片头指针
导出函数返回 Go 内存会 panic，别这么干
CGO 导出给 C 调用的函数（即带 //export Foo 注释的函数），返回值若是指向 Go 分配内存的指针（如 *C.char 指向 Go 字符串底层），运行时会直接触发 panic: cgo result has Go pointer。
- 错误写法：
func ExportGetString() *C.char { return C.CString("hello") } - 正确做法：要么让 C 分配目标内存并由 C 侧 free（如传入 buffer + size）；要么返回整数 ID，由 C 通过另一个导出函数查表取值
- 这个 panic 是 Go 运行时强制拦截，不是可忽略的 warning
- 如果必须返回字符串，可用
C.CString+ 让 C 侧约定调用C.free，但需文档强约束，且无法被类型系统保障
用 defer + 工具扫描双保险
单靠人肉检查容易漏，尤其嵌套调用或 error early return 场景。必须结合语言机制和静态检查。
- 所有
C.CString/C.CBytes后紧跟defer C.free(unsafe.Pointer(x))，哪怕只用一行 - 用
grep -r "C\.CString\|C\.CBytes" --include="*.go" .扫描全项目，人工核对每处是否配对 - 启用
go vet -vettool=$(which cgo)（新版 go vet 内置 cgo 检查），能报出部分未释放警告 - 上线前跑内存压测，用
go tool pprof -inuse_space对比前后，重点关注C.malloc相关调用栈（pprof 不直接显示 C 堆，但泄漏会反映为 Go 侧持续增长的 inuse）
最危险的不是不会写 C.free，而是写了但被条件分支绕过，或者 defer 放在了错误的作用域里——比如放在 if 分支内，而 error path 没覆盖。这类问题只有压测 + pprof + 代码扫描三者交叉验证才能兜住。
