CGO返回的C指针不调用C.free会导致确定性内存泄漏，因Go GC不管理C分配内存，常见表现为OOM或RSS持续上涨；仅C侧分配（如C.CString、C.CBytes、C.malloc）需free，且须判空、防重释放、单goroutine释放。
CGO返回的C指针不free会怎样
Go运行时不会自动追踪或释放C分配的内存，C.malloc、C.CString、C.CBytes等返回的指针完全脱离Go的GC体系。只要没调用C.free，那块内存就一直占着——不是“可能泄漏”，是确定泄漏，且无法被回收。
- 常见错误现象：
runtime: out of memory或进程RSS持续上涨，pprof查不到Go堆对象增长 - 使用场景：调用C库返回字符串（如
char*）、结构体数组、二进制缓冲区（如图像数据、加密结果） - 关键点：只有C侧用
malloc/类似函数分配的内存才需要C.free；Go传给C的指针（如&x）绝不能C.free
什么时候必须手动调用C.free
不是所有C指针都要free，只看内存谁分配的：
-
C.CString("hello")→ 必须C.free(unsafe.Pointer(cstr)) -
C.CBytes([]byte{1,2,3})→ 必须C.free(ptr) -
C.malloc(C.size_t(1024))→ 必须C.free(ptr) - 但
C.getenv("PATH")返回的指针通常指向环境变量只读区，C.free会崩溃 - C函数文档明确写“caller must free”或返回值标注为
char* malloc风格时，才free
在Go里安全释放的三个实操要点
C.free本身不检查空指针或重复释放，出错直接SIGSEGV：
- 释放前务必判空：
if ptr != nil { C.free(ptr) } - 不要多次释放同一指针（包括在defer里和函数末尾都写一次）
- 如果指针要跨goroutine传递，确保只有一个goroutine负责free（常见坑：goroutine池中误重复释放）
- 推荐模式：分配后立刻用
defer配对，但注意defer在函数return时才执行，若函数提前panic且没recover，可能漏掉；更稳的是在明确作用域结束处显式free
ptr := C.CString("data")
defer C.free(unsafe.Pointer(ptr)) // OK，但仅限本函数内使用完即弃
// 后续用ptr做事情...
替代方案：能不用C.free就尽量避免
手动管理C内存是反模式的下策，优先考虑：
立即学习“go语言免费学习笔记（深入）”；
- 用Go原生类型替代：比如C函数支持传入
char* buf, size_t len，就预分配[]byte，用unsafe.Slice转指针，不申请新内存 - 封装成Go结构体+finalizer（慎用）：
runtime.SetFinalizer可兜底，但不保证及时执行，仅作泄漏防护，不能替代主动free - C侧改用栈分配或静态缓冲区（需改C代码，但最安全）
真正麻烦的从来不是怎么free，而是忘了在哪一层分配、被谁持有、生命周期是否跨协程——这些信息不会出现在编译错误里，只能靠约定和代码审查盯住。
