C.CString 和 C.GoString 是性能瓶颈，因其强制深拷贝：前者每次 malloc 复制并加 \0，后者每次 strlen 扫描再 malloc+memcpy；误用 defer 会导致内存泄漏或崩溃。
为什么 C.CString 和 C.GoString 是性能瓶颈
这两个函数在循环中高频调用时，会直接拖垮性能。根本原因不是“慢”，而是强制深拷贝：每次 C.CString 都在 C 堆上 malloc 一块新内存，复制 Go 字符串内容并加 \0；每次 C.GoString 都要 strlen 扫描 C 字符串长度，再 malloc + memcpy 回 Go 堆。哪怕传空字符串，也走完整路径。
更危险的是误用模式：for i := range data { cstr := C.CString(data[i]); defer C.free(cstr) } —— 这里 defer 绑定的是上一轮的 cstr 地址，当前轮分配的内存根本没释放，必然泄漏或崩溃。
用 C.CBytes 替代 C.CString 处理只读字符串
当 C 函数签名支持显式长度参数（如 foo(const char* s, size_t n)），就完全绕开 C.CString。
-
C.CBytes([]byte(s))返回*C.uchar，不加\0，不验证 UTF-8，不扫描终止符，纯字节搬运 - 配合
C.size_t(len(s))一起传入，C 端按长度安全读取 - 避免了 C 堆 malloc/free 开销，也规避了悬空指针风险（因为没用
C.CString分配的内存）
示例：ret := C.process_data((*C.char)(C.CBytes([]byte(input))), C.size_t(len(input)))
立即学习“go语言免费学习笔记（深入）”；
C.GoStringN 比 C.GoString 更安全可控
当 C 函数返回一个带长度信息的 *C.char（比如从 C 缓冲区截取、或由 C 层明确告知长度），绝不要用 C.GoString。
-
C.GoString内部调用strlen，一旦 C 端字符串没正确以\0结尾，就会越界扫描，可能 crash 或卡死 -
C.GoStringN(cstr, n)直接按你给的n截取，不依赖\0，也不触发 strlen - 尤其适合解析 C 层固定长度字段、二进制协议头、或从 C malloc 缓冲区中切片出来的子串
示例：goStr := C.GoStringN(c_result_ptr, C.int(result_len))
复用 C 堆内存而非反复分配
对高频调用的 C 接口，把 C 堆内存生命周期绑定到 Go 对象上，是最有效的优化手段。GC 不管 C 堆，所以不能靠 unsafe.Slice 包装后丢给 GC —— 切片头可能被回收，而 C 函数还在用底层指针。
- 用
C.malloc+C.free手动管理一块固定缓冲区，例如buf := (*C.char)(C.malloc(4096)) - 在 Go struct 中保存该指针，并实现
Close()或Free()方法显式调用C.free - 所有字符串写入都用
C.memcpy到该缓冲区，长度严格控制，末尾手动补\0（如果 C 函数需要）
关键点：这块内存的生命周期必须由 Go 代码显式控制，不能依赖临时转换语义或 defer —— 否则极易漏 free 或提前 free。
