go字符串转c数组时易panic，因c.cstring分配c堆内存且不处理\0终止符，若原串含\0或malloc失败未检查返回值，会导致越界读取或空指针崩溃；安全做法是手动控制长度、显式写入\0终止符。
Go字符串转C数组时为什么一传就panic？
因为C.CString分配的是C堆内存，而Go string本身不带\0终止符；若原字符串含\0或长度超限，C.CString会截断到首个\0，但调用方若误以为整段都有效，后续C函数越界读取就会触发SIGSEGV或数据错乱。更危险的是：Go侧未检查C.CString返回值是否为nil（malloc失败时），直接解引用会导致空指针崩溃。
如何安全地把Go字符串塞进固定长度C数组？
不能直接copy(C.deviceName[:], []byte(gostr))——Go字符串不含\0，C端读取会越过数组边界。必须显式控制长度和终止符：
- 先用
utf8.RuneCountInString(gostr)算字符数，再按目标编码（如GBK）预估字节数，确保不超过C数组容量 - 用
bytes := []byte(gostr)获取底层字节，然后copy(C.deviceName[:len(bytes)], bytes) - 手动在末尾写
\0：C.deviceName[len(bytes)] = 0（前提是len(bytes) ） - 若
gostr含\0，[]byte(gostr)仍保留它，需提前strings.ReplaceAll(gostr, "\x00", "")过滤
导出函数接收C字符串时最常踩的坑
用//export导出给Java/Python调用的函数，参数绝不能声明为string——C ABI根本不认识Go的string结构体。运行时会把传入的char*地址当指针字段，紧邻8字节当长度字段，结果解析出一个天文数字导致runtime.concatstring3申请TB级内存直接OOM。
正确写法只有这一种：
//export Hello
func Hello(s *C.char) {
if s == nil {
return
}
goStr := C.GoString(s) // 安全读到\0为止，自动分配新字符串
// ... 使用goStr
}
注意：C.GoString内部已处理空指针和\0边界，无需额外判断长度；但它不校验编码，若C端传入非法UTF-8，goStr仍为合法字符串（只是内容可能乱码）。
C.CString分配的内存谁来管？
归你管。它调用的是malloc，不是Go堆，GC完全无视。常见错误是：
- 在循环里反复
C.CString却不C.free→ 内存泄漏 - 把
C.CString结果存进全局C变量或回调上下文 → Go函数返回后指针悬空，C侧再访问就是UB - 用
defer C.free但在goroutine里调用 → defer不执行，泄漏
唯一稳妥做法：每次C.CString配对一次C.free，且确保在同一线程、同一函数作用域内完成。如果C函数要长期持有该指针，必须改用C.CBytes + 手动管理生命周期，或让C侧负责释放。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
