c.cstring将go字符串转为 c.char需配对c.free，c.gostring将 c.char转go string；c结构体指针须指向c分配内存，避免悬空；import "c"强制启用cgo，cgo_enabled=0时会报错。
CGo调用C函数时，char* 和 *C.char 怎么互转？
Go 里没有 char<em></em>，只有 C.char —— 这是 CGo 自动生成的 C 兼容指针类型。直接传 string 或 []byte 会编译失败。
-
C.CString("hello")把 Go 字符串转成 C 的堆内存字符串，返回*C.char；必须配对调用C.free()，否则内存泄漏 -
C.GoString(cstr)把*C.char转成 Gostring（拷贝内容，安全）；C.GoStringN(cstr, n)用于带长度、可能含 \0 的场景 - 别用
unsafe.String()或(*reflect.StringHeader)(unsafe.Pointer(&s)).Data去“绕过转换”——这在 Go 1.22+ 极易触发 panic，且破坏 GC 对字符串的管理
// 正确示例
cstr := C.CString("path/to/file")
defer C.free(unsafe.Pointer(cstr)) // 必须 defer，不能忘
ret := C.some_c_func(cstr)
result := C.GoString(ret)
结构体字段含指针时，C.struct_xxx 为什么一用就崩溃？
CGo 生成的 C.struct_xxx 是纯 C 内存布局，但 Go 不知道它内部指针指向哪。如果 C 结构体里有 char<em></em> 成员，而你用 C.malloc 分配了整个结构体，再手动填 C.char，那这个指针在 Go 看来就是“悬空”的——GC 不会追踪，C 层也可能提前释放。
- 所有 C 结构体中的指针字段，必须指向 C 分配的内存（如
C.CString、C.malloc），不能指向 Go 的string底层或局部变量地址 - 如果结构体由 C 函数返回（比如
some_init()返回*C.struct_config），别在 Go 里直接读写其指针字段；应通过 C 封装函数访问，或用C.GoString立即拷出内容 - 避免在 Go 中长期持有
C.struct_xxx实例：它的生命周期完全依赖 C 层管理逻辑，Go 无法干预
用 C.malloc 分配内存后，什么时候该 C.free？
C.malloc 返回的是裸 C 指针，Go 的 GC 完全不感知。不 C.free 就是稳稳的内存泄漏；过早 C.free 则后续访问触发 segfault。
- 规则只有一条：谁分配，谁释放；且必须在 C 层使用完之后、Go 层不再需要之前释放
- 如果 C 函数返回一个需用户释放的指针（常见于
xxx_new()/xxx_free()成对 API），Go 层必须用defer C.free(unsafe.Pointer(p))包裹整个使用块 - 别把
C.malloc的结果存进 Go 的全局变量或 map 里——容易漏掉free，也难追踪生命周期 -
C.CString本质也是C.malloc+strcpy，所以同样适用这条规则
开启 CGO_ENABLED=0 后，为什么 import "C" 直接报错？
import "C" 不是普通导入，而是 CGo 的语法锚点。只要文件里有它，构建时就强制启用 CGo；设 CGO_ENABLED=0 会导致预处理失败，报类似 could not determine kind of name for C.xxx 的错误。
立即学习“go语言免费学习笔记（深入）”；
- 如果你写的是纯 Go 库但留了
import "C"（哪怕下面没 C 代码），构建就会失败 - 交叉编译到无 libc 环境（如 linux/mips64le 或嵌入式）时，不是靠关 CGo 解决，而是得确保 C 依赖本身可移植（比如用 musl 替代 glibc，或改用纯 Go 实现）
- 真要条件编译 C 代码，得用 build tag + 单独的
.c文件，Go 文件里不要留空的import "C"
C 代码和 Go 的边界比看着薄，实际是两套内存模型、两套生命周期规则在贴身换挡。最容易出问题的从来不是“怎么写”，而是“哪边负责释放”“谁在什么时候还能碰这块内存”。多看 C 头文件里的注释，尤其是 caller must free 或 returns borrowed pointer 这类提示，比查 Go 文档还管用。
