go字符串传给c函数必须用c.cstring并配对c.free，因go字符串只读且受gc管理，而c要求可写、以\0结尾的独立内存；空字符串需特殊处理，结构体对齐和c回调时的字符串拷贝也须谨慎。
Go字符串传给C函数时，不显式拷贝就会崩溃；哪怕拷贝了，对齐不对也会读错数据——这不是bug，是内存模型差异的必然结果。
为什么 C.CString 必须调用且不能省略
Go的string是只读结构体（含指针+长度），底层内存由GC管理；C的char*要求以\0结尾、内存可自由读写。两者生命周期和所有权模型完全不兼容。
常见错误现象：
- 直接传
&s[0]或unsafe.StringData(s)：GC可能在C函数执行中途移动/回收该内存，导致SEGFAULT或脏数据 - 用
C.CString但没C.free：C堆内存泄漏，长期运行后OOM - 传空字符串
""给C.CString：返回nil，C端未判空直接解引用 → 崩溃
正确做法：
- 总是用
C.CString(s)生成独立C内存块 - 在C函数返回后，立即用
C.free(unsafe.Pointer(cstr))释放 - 空字符串需单独处理：
cstr := C.CString(s); if cstr == nil { cstr = C.CString("") }
结构体里嵌字符串字段时，C.CString 生成的指针怎么对齐
当Go结构体通过unsafe.Pointer转成C结构体指针时，字段地址必须满足C端对齐要求。而C.CString返回的是*C.char，其地址本身由C堆分配器决定，不保证与结构体起始地址对齐。
典型问题场景：
- C结构体定义含
char* name字段，且该字段偏移量要求是8字节对齐（如64位平台） - Go结构体中
Name *C.char字段紧挨着一个int32，导致该指针字段实际偏移为12字节 → 不满足C端预期
解决方案：
- 不用
*C.char字段，改用[256]C.char固定数组（需提前知最大长度），避免指针跳转 - 若必须用指针，在Go结构体中手动填充：
_ [4]byte确保后续*C.char落在8字节边界 - 更稳妥的做法：C端结构体用
char name[]柔性数组，Go端用C.CBytes拼接整个结构体内存块，一次性分配并控制布局
从C回调Go函数时，字符串参数为什么总为空或乱码
C回调Go函数（通过//export）时，C传入的char*若来自栈或临时缓冲区，Go函数返回后该内存即失效。此时用C.GoString读取看似正常，实则依赖未定义行为。
关键细节：
-
C.GoString(cstr)会复制C字符串内容到Go堆，但前提是cstr在调用瞬间有效 - 如果C端用
char buf[64]; strcpy(buf, "hello"); callback(buf);，buf是栈变量，回调返回后即销毁 - 某些C库（如libuv）会复用回调参数内存，下一次回调覆盖上一次内容
安全做法：
- 在Go回调函数内立刻调用
C.GoString或C.GoStringN完成拷贝 - 不要缓存
*C.char指针供后续使用 - 对不定长字符串，优先用
C.GoStringN(cstr, C.int(n))，避免依赖\0终止符
性能敏感场景下，如何绕过C.CString的拷贝开销
高频调用（如每毫秒数百次）时，C.CString的malloc/free成为瓶颈。但直接暴露Go字符串底层数组风险极高。
可行折中方案：
- 用
C.CBytes([]byte(s))替代C.CString：避免\0扫描，稍快；仍需C.free - 预分配C内存池：启动时用
C.malloc申请大块内存，按需切片复用，自行管理生命周期 - 仅当C函数声明为
const char*且只读时，可用unsafe.StringData+runtime.KeepAlive钉住Go字符串，但必须确认C函数不会跨goroutine或异步持有指针
最易被忽略的一点：所有绕过C.CString的方案，都要求你明确承担内存生命周期责任——Go GC不管C堆，C也不管Go字符串，谁分配谁释放，错一环就崩。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
