cgo内存安全的核心在于明确Go与C的内存管理边界：C.CString+defer在循环中因变量复用导致泄漏；应优先用C.CBytes+C.GoStringN避免深拷贝和strlen开销；导出函数需C端显式声明类型；C持有的内存必须由C释放，不可依赖finalizer。
cgo 调用本身不崩溃、不 panic，但绝大多数 segfault、内存泄漏、随机 crash 都来自 Go 和 C 内存边界的失守——不是写法错，是模型混用却没意识到它们根本不兼容。
为什么 C.CString + defer C.free 在循环里会悄悄泄漏
这不是语法错误，是执行逻辑陷阱：defer 绑定的是变量名，不是调用时的地址值。
- 写
for _, s := range strs { cs := C.CString(s); defer C.free(unsafe.Pointer(cs)) }→ 所有defer都注册在同一个cs变量上，最终只释放最后一次分配的地址，前面全漏 -
C.CString("")仍会 malloc 一块带\0的内存；不C.free，它就永远卡在 C 堆里 - 若 C 函数内部保存了该指针（比如注册为回调 buffer），
defer C.free在 Go 函数返回时就释放了，C 侧再读就是 invalid read
传字符串给 C 函数时如何避免深拷贝和 UTF-8 验证开销
绕过 C.CString 和 C.GoString 这两个“黑洞”，改用长度可控、无零终止依赖的接口。
- 若 C 函数支持长度参数（如
void process(const char* s, size_t n)），用C.CBytes([]byte(s))→ 返回unsafe.Pointer，再转(*C.char)，显式传长度 -
C.CBytes不检查内容，比C.CString快一个数量级，适合高频或大文本场景 - 只读接收 C 字符串时，用
C.GoStringN(cstr, n)替代C.GoString(cstr)，跳过 C 侧strlen扫描 - 绝不要对
C.CBytes返回的指针做unsafe.Slice(ptr, n)当[]byte用——底层内存不受 GC 管理，切片头可能被回收而指针仍在使用
Go 导出函数给 C 调用时，C 侧必须显式声明类型
隐式函数声明（C89 风格）会导致栈帧错乱：C 编译器默认认为未声明函数返回 int，而 Go 导出的是 char*，类型不匹配直接触发 SIGSEGV。
立即学习“go语言免费学习笔记（深入）”；
- C 头文件中必须写明：例如
char* c_ccB(char*);，不能只靠#include "p.h"就指望编译器猜 - C 实现里调用该函数前，必须确保该声明已可见（推荐统一放在头文件，而非仅
extern行内补） - Go 侧导出函数返回的
C.CString，必须由 C 代码负责释放（free(result)），Go 不能假设自己能管到底
复用 C 内存时为什么不能依赖 finalizer
runtime.SetFinalizer 不保证及时性，且可能在 C 还在用内存时触发释放——这是悬垂指针的温床。
- 手动管理生命周期是唯一可靠方式：Go struct 持有
unsafe.Pointer和长度，在 Close() 方法里统一C.free - 若 C 库需长期持有缓冲区（如音视频解码器 input buffer），必须设计引用计数或 ID 映射表，不能靠 Go 变量作用域自动清理
- 传给 C 函数时，直接转
(*C.char)(ptr)；C 侧必须严格按传入长度操作，越界写会破坏相邻 Go 内存
真正难的从来不是“怎么写”，而是每次跨过 import "C" 那一行时，你是否清楚此刻控制权移交给了谁、内存归谁管、指针有效期到哪一秒。边界模糊的地方，从来不会报错，只会等你上线后某个凌晨三点才爆发。
