cgo调用单次开销为50–200ns，远高于纯go函数调用；其本质是每次调用都需暂停goroutine、切换系统线程、重置信号掩码并适配c abi，而非简单“慢一点”。
CGO 调用不是“慢一点”，而是每次都要暂停 goroutine、切换到系统线程、重置信号掩码、适配 C ABI——单次开销实测 50–200 ns，远超纯 Go 函数调用（
为什么 C.CString 和 C.GoString 是高频调用的性能黑洞
这两个函数看似只是字符串转换，实际强制深拷贝：前者分配 C 堆内存并复制字节+加 \0，后者从 C 字符串 malloc 新 Go 字符串并复制。哪怕传空字符串，也走完整路径。
- 循环中写
for _, s := range strs { cstr := C.CString(s); defer C.free(cstr) }→ 每次都 new 内存，defer却 free 上一轮地址，直接泄漏或崩溃 - 若 C 接口支持长度参数（如
foo(const char* s, size_t n)），改用C.CBytes([]byte(s))+ 显式长度，跳过 UTF-8 验证和strlen扫描 - 对只读 C 字符串，用
C.GoStringN(cstr, n)替代C.GoString(cstr)，避免 C 端调用strlen查末尾
如何批量调用 C.process_batch 替代循环内 C.process_one
高频小粒度调用是 CGO 最典型的性能误用。Go 侧每毫秒调 10 万次 C.process_one，不如一次传整块数据进 C，由 C 层 for 循环处理。
-
C函数签名需支持切片式输入，例如void process_batch(const float* in, float* out, int n) - Go 侧传
(*C.float)(unsafe.Pointer(&data[0]))，而非逐个转指针 - 若原 C 库无批量接口，可自己写一层 C 封装（不带 class/template，仅
extern "C"函数） - 注意：C 层必须校验
n，防止越界写覆盖相邻内存
如何安全复用 C.malloc 分配的内存而不交由 GC 管理
C 堆内存不受 Go GC 控制。把 C.malloc 返回的 unsafe.Pointer 直接包成 []byte 丢给 GC，等于埋雷——GC 可能回收切片头，而 C 函数还在往底层地址写。
- 在 Go struct 中保存
ptr unsafe.Pointer和size int，封装WriteToC()/ReadFromC()方法 - 初始化时一次性分配，如图像缓冲区：
ptr := C.malloc(w * h * 4)，整个生命周期复用 - 释放必须唯一：在 struct 的
Close()或Free()中调C.free(ptr)，绝不依赖defer跨 goroutine 传递 - 传给 C 函数时转为
(*C.char)(ptr)，C 侧需严格按长度访问，不可越界
真正难的不是写对 import "C"，而是判断哪段逻辑该留在 Go、哪段必须下沉到 C；不是堆内存怎么 free，而是谁负责 lifetime —— C 侧写死的 buffer 大小、Go 侧动态增长的 slice、中间传递的长度参数，三者稍有错位，就是越界或泄漏。这些边界，没法靠工具自动检查，得靠人盯住。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
