Go字符串传给C后崩溃或乱码是因为GC可能提前回收底层内存，runtime.KeepAlive仅在C保存指针且Go无其他引用时需显式使用，正确用法是作用于原始字符串变量s而非cs。
为什么 Go 字符串传给 C 后会崩溃或读到乱码
因为 runtime.KeepAlive 不是“让字符串活得久一点”的万能补丁，而是告诉 Go 编译器：这个变量在某行代码之后**仍被 C 侧逻辑实际使用**。Go 的 GC 可能在 C 函数调用返回前就回收掉临时的 C.CString 对应的 Go 字符串底层数组——尤其当 Go 侧没其他引用、且 C 函数执行时间稍长或异步时。
典型现象：unexpected fault address、signal SIGSEGV、C 读到空或随机内存内容。这不是 C 代码写错了，而是 Go 提前交出了内存控制权。
什么时候必须加 runtime.KeepAlive
只在以下情况需要显式干预：
- C 函数接收的是
*C.char（即由C.CString分配的内存），且该指针会被 C 侧**保存、延迟使用或跨函数生命周期访问**（比如注册回调、塞进结构体、存入全局队列） - Go 侧在调用 C 函数后，**没有其他变量持有原字符串或其底层字节数组的引用**（例如没赋值给字段、没传入闭包、没存 map）
- C 函数本身是同步返回的，但内部触发了异步行为（如启动线程、投递事件）
如果只是 C.puts(C.CString("hello")) 这种瞬时调用，不需要 runtime.KeepAlive —— C 函数返回时 Go 还没开始 GC 扫描，自然安全。
立即学习“go语言免费学习笔记（深入）”；
runtime.KeepAlive 放在哪一行才有效
它必须放在 C 函数调用之后、且**确保在 C 侧真正停止使用该指针之前不被 GC 扫描到**。常见错误是放太早（没覆盖 C 使用点）或放太晚（GC 已发生）。
正确姿势：
cs := C.CString(s) defer C.free(unsafe.Pointer(cs)) C.register_callback(cs) // C 保存了 cs 指针 runtime.KeepAlive(s) // ✅ 关键：s 是源字符串，KeepAlive 必须作用于它（不是 cs！） // 后续可能还有其它 Go 逻辑，但只要 s 不再被 Go 引用，这里就是最后的安全锚点
注意：runtime.KeepAlive 的参数必须是原始 Go 字符串变量（s），不是 cs 或 unsafe.Pointer —— 它靠跟踪栈上变量的生命周期来阻止 GC 回收底层数据。
比 runtime.KeepAlive 更稳妥的替代方案
KeepAlive 是“打补丁”，治标不治本。真正健壮的做法是切断 Go 字符串与 C 持有指针之间的生命周期耦合：
- 用
C.CBytes([]byte(s))替代C.CString，然后手动管理内存（C.free），并确保 C 侧拷贝走数据而非直接引用 - 在 C 侧做深拷贝（
strdup或malloc+memcpy），Go 侧调用完立刻C.free，把所有权完全移交给 C - 如果 C 接口支持，改用
*C.char+ 长度参数，让 C 只读取不保存，避免跨生命周期引用
KeepAlive 容易漏写、位置敏感、且掩盖了内存所有权不清晰的问题。遇到多线程回调或长期驻留的 C 结构体，优先考虑内存拷贝或明确所有权移交。
