直接转string不会崩溃，崩溃源于误用c.gostringptr或未配对c.free；c.gostring安全复制，c.gostringptr依赖c内存长期有效，需手动c.free防止泄漏。
Go调用C函数后拿到*C.char，为什么直接转string会崩溃？
因为C返回的*C.char指向的内存可能由C侧动态分配（比如malloc），也可能指向栈上临时数据；Go的C.GoString只是按\0截取并拷贝内容，不接管原始指针生命周期。如果C侧后续free了那块内存，而你又在Go里反复用这个string——其实没问题，因为C.GoString已复制一份；但如果你误用C.GoStringPtr或自己用C.CString反向传回C，就容易踩到悬空指针。
-
C.GoString(ptr)安全：它内部malloc新内存、strcpy、再转成Gostring，和原ptr完全解耦 -
C.GoStringPtr(ptr)危险：它假设ptr长期有效，且指向以\0结尾的C字符串；一旦C侧释放或复用该内存，Go侧读取就会panic或返回脏数据 - 常见错误现象：
signal SIGSEGV: segmentation violation或输出乱码，尤其在多轮调用后出现
什么时候必须手动C.free？
仅当你用C.CString从Go往C传字符串，或C函数明确文档写“caller must free”并返回由malloc/类似方式分配的*C.char时，才需要在Go里配对调用C.free。Go不会自动跟踪这些C内存。
- 典型场景：C函数如
char *get_config_path(void)内部用strdup或malloc+strcpy返回路径字符串 - 正确做法：
pathC := C.get_config_path() defer C.free(unsafe.Pointer(pathC)) pathGo := C.GoString(pathC)
- 错误做法：只调
C.GoString就扔掉pathC，导致C侧内存泄漏（尤其循环调用时） - 注意：
C.free只能用于malloc/calloc/realloc分配的内存，不能用于栈变量、全局数组或C++new出来的指针
C.GoString的性能开销在哪？
每次调用都涉及一次内存分配（Go堆上）和逐字节拷贝，直到遇到<p>每次调用都涉及一次内存分配（Go堆上）和逐字节拷贝，直到遇到<code>\0。对短字符串影响小，但若C返回的是几MB的日志文本，频繁调用C.GoString会触发GC压力、拖慢吞吐。
C.GoString会触发GC压力、拖慢吞吐。
- 替代方案：如果确定C字符串生命周期长于当前函数作用域，且你只需要读取（不传给其他Go goroutine），可用
C.GoStringN限制长度避免越界扫描 - 更激进优化：用
unsafe.Slice（Go 1.17+）配合C.strlen构造[]byte切片，再转string（零拷贝，但要求你确保底层内存不被C侧释放） - 兼容性注意：旧版Go（unsafe.Slice，需用
reflect.SliceHeader黑魔法，风险更高
跨goroutine共享C字符串时最常漏掉什么？
不是线程安全问题，而是所有权混淆。Go的string本身是只读且不可寻址的，但它的底层数据如果来自C.GoString，那没问题；如果来自unsafe方式构造的切片，而该切片底层数组绑定的是C分配的内存——那就必须确保所有goroutine访问完毕后，才调C.free。
立即学习“C语言免费学习笔记（深入）”；
- 最容易被忽略的点：用
sync.WaitGroup等同步机制控制goroutine生命周期，但忘了把C.free放到最后一个goroutine退出之后 - 一个稳妥做法：把C指针和
sync.Once封装进结构体，Free()方法用Once.Do保证只释放一次 - 别依赖GC：Go GC完全不管理
C.malloc出来的内存，也不会触发C.free
