c.cstring 不泄漏，漏的是未调用 c.free；defer 在循环中失效因绑定变量值而非每次地址；正确做法是用匿名函数闭包或 c.cbytes 配显式长度，导出函数应避免直接返回 *c.char。
C.CString 本身不泄漏，漏的是你没调用 C.free。它每次调用都走 libc malloc，Go 的 GC 完全看不见那块内存，不手动 free 就永远卡在 C 堆里——高并发下几秒涨几十 MB 是常态。
为什么 defer C.free(unsafe.Pointer(cs)) 在循环里会失效
常见错误写法：for _, s := range strs { cs := C.CString(s); defer C.free(unsafe.Pointer(cs)) }。问题不在 defer 本身，而在于 Go 中 defer 绑定的是变量 cs 的**值**，不是每次调用时的地址。所有 defer 最终都指向最后一次分配的 cs 地址，前面的全漏。
- 正确做法：把字符串处理逻辑拆成独立函数，每次调用都带自己的
defer - 或改用
func() { cs := C.CString(s); defer C.free(unsafe.Pointer(cs)); someCFunc(cs) }()匿名函数闭包 - 更稳妥的是直接用
C.CBytes([]byte(s))+ 显式长度传参，避免零终止依赖，且同样要defer C.free
替代 C.CString 的安全方案（不拷贝 / 不泄漏 / 不 panic）
如果你控制得了 C 函数签名，优先绕开 C.CString 和 C.GoString 这两个“黑洞”：
- 让 C 函数接受
const char* s, size_t n形参 → Go 侧用C.CBytes([]byte(s))转unsafe.Pointer，再转(*C.char)，显式传长度 -
C.CBytes不做 UTF-8 验证、不加\0、不扫描长度，比C.CString快一个数量级 - 绝对不要对
C.CBytes返回的指针做unsafe.Slice(ptr, n)当[]byte用——底层内存不受 GC 管理，切片头可能被回收而指针还在用 - 只读场景接收 C 字符串时，用
C.GoStringN(cstr, n)替代C.GoString(cstr)，跳过 C 侧strlen扫描
导出函数返回字符串时怎么避免泄漏
写 //export GetResult 函数并返回 *C.char 是危险操作：func GetResult() *C.char { return C.CString("ok") } 会导致 panic：“cgo result has Go pointer”，因为 Go 运行时强制拦截这种返回 Go 分配内存的导出行为。
- 正确做法一：让 C 侧分配 buffer，Go 侧只 copy 数据进去（
C.memcpy），由 C 侧负责释放 - 正确做法二：返回整数 ID，C 侧通过另一个导出函数（如
//export GetStringByID）查表取值，配合引用计数或 ID 映射表管理生命周期 - 若必须返回 C 字符串，得在文档里强约定“调用方必须用
C.free释放”，但类型系统无法保障，容易漏
最易被忽略的一点：C.CString("") 仍会 malloc 一块带 \0 的内存，不 C.free 就永远不还；error early return 路径里漏掉 defer 比正常路径更常见——别信“后面会 free”的注释，grep 全项目核对 C.CString 和 C.free 是否严格配对才是硬道理。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
