cgo中c.cstring分配的内存不释放会导致持续内存泄漏，rss不断上升直至oom；必须配对c.free，且需根据c函数文档判断返回指针是否需手动释放。
CGO返回的C字符串不释放会怎样
直接泄漏，且Go的GC完全不管——C.CString分配的是C堆内存，Go运行时既不追踪也不回收。进程长期运行时，malloc出来的内存只增不减，top里RSS持续上涨，最终OOM。
常见错误现象：runtime: out of memory 或系统级 Killed process（被OOM Killer干掉）；但更隐蔽的是小规模泄漏长期积累，压测几天后才暴露。
- 每次调用
C.CString都必须配对C.free，不能依赖defer（除非确保作用域内完成） - 如果C函数返回的是
*C.char（比如C.getenv），它可能指向静态内存或malloc内存，得看文档——多数情况需用C.CString复制后再处理，避免悬垂指针 - 别把
C.CString结果传给Go的string()就完事：这只会复制字节，原始C内存还在那儿
手动释放C分配内存的正确姿势
核心就一条：谁 malloc，谁 free；CGO里基本就是谁调用 C.CString / C.malloc，谁负责 C.free。
典型安全写法：
立即学习“go语言免费学习笔记（深入）”；
// ✅ 正确：分配后立即绑定释放逻辑
cstr := C.CString("hello")
defer C.free(unsafe.Pointer(cstr))
<p>// ✅ 更稳妥：在明确作用域末尾 free，避免 defer 在 panic 时失效
cstr := C.CString(data)
// ... 使用 cstr
C.free(unsafe.Pointer(cstr))
cstr = nil // 防重复 free-
C.free接收unsafe.Pointer，必须显式转换，不能直接传*C.char - 重复
C.free同一块内存 →double free，大概率 crash，错误信息类似glibc detected *** free(): invalid pointer - 释放后继续读写该指针 → 典型 use-after-free，行为未定义，可能崩溃也可能静默错乱
从C函数接收内存时怎么判断要不要 free
没有银弹，必须查C函数文档或源码。但有几条硬规则可快速判断：
- 函数名含
alloc、new、copy、dup（如C.strdup）→ 你负责free - 返回值是全局变量、静态缓冲区（如
C.getpwuid返回的*C.struct_passwd中的pw_name）→ 不要free，它是只读的 - 函数文档写明 “caller must free” 或 “the caller is responsible for freeing the memory” → 必须
free - 不确定？宁可
strace看系统调用，或用valgrind --tool=memcheck（需编译为非PIE）验证
例如：C.getenv 返回的是环境变量指针，属于进程数据段，绝不能 C.free；而 C.CString(os.Getenv("X")) 是你 malloc 的，必须 free。
用 Go string 和 []byte 和 C 交互时的隐性内存风险
表面看只是类型转换，实则暗藏两层内存：Go 的底层数组 + C 的 malloc 缓冲区。最容易漏的是「只转了类型，没管底层分配」。
-
C.CString(string)→ 新分配C内存，必须C.free -
C.GoString(*C.char)→ 复制C字符串到Go堆，C内存仍存在，是否free取决于来源 -
C.GoBytes(unsafe.Pointer, len)→ 同样只复制，不释放原C内存 - 想零拷贝传
[]byte给C？用unsafe.Slice+unsafe.Pointer(&slice[0])，但必须确保Go切片生命周期 > C函数调用期，否则GC可能回收
一个真实坑点：用 C.CString 转一堆日志字符串打点，忘了 free，单次请求多几个字段，QPS 上千时每秒泄漏几MB，一小时就吃光容器内存。
复杂点永远在边界上：C库版本升级改了内存管理语义、跨线程传递指针、C回调里保存Go字符串的C副本……这些地方不靠工具很难覆盖全。上线前至少跑一次 go tool cgo -godefs 检查头文件绑定，再加一轮 valgrind 内存扫描。
