Go禁止传递含Go指针的Go数据结构（如[]*C.char）给C，因GC无法追踪嵌套指针；合规做法是两段分配：字符串用C.CString、指针数组用C.malloc，并手动管理内存。
Go 通过 cgo 传递指针给 C 是可行的，但必须严格遵守内存所有权和指针层级规则；直接传 []*C.int 或 []string 的底层指针会触发 cgo argument has Go pointer to Go pointer panic，根本原因不是“不能传指针”，而是 Go 运行时无法追踪嵌套的 Go 指针引用。
为什么 unsafe.Pointer(&slice[0]) 对 []*C.char 失败
当你写 ps := []*C.char{C.CString("a"), C.CString("b")}，再试图用 unsafe.Pointer(&ps[0]) 传给 C 函数，Go 会拒绝——因为 ps 是 Go 分配的切片，其底层数组元素本身是 Go 指针（指向 C 堆内存），构成“Go pointer to Go pointer”结构。Go GC 无法保证这些指针值在 C 函数执行期间不被移动或失效。
- 错误现象：
panic: cgo argument has Go pointer to Go pointer - 本质限制：cgo 禁止任何含 Go 指针的 Go 数据结构（如切片、struct）直接跨边界传入 C
- 对比安全操作：
C.CString("hello")返回*C.char，这是纯 C 指针，可安全传；&someCInt（C 栈变量地址）也可传
传递 []string 到 char** 的合规步骤
核心是“两段分配”：字符串内容用 C.CString 分配在 C 堆，指针数组本身也必须用 C 内存（如 C.malloc）分配，避免 Go 控制指针容器。
- 先为指针数组申请 C 内存：
ptrs := (*C.char)(C.malloc(C.size_t(len(goStrings)) * C.size_t(unsafe.Sizeof(uintptr(0))))) - 逐个调用
C.CString(s)，得到每个*C.char，再用(*(*C.char)(unsafe.Pointer(uintptr(unsafe.Pointer(ptrs)) + uintptr(i)*unsafe.Sizeof(uintptr(0)))) = cstr写入 C 数组 - 传给 C 函数时，用
(**C.char)(unsafe.Pointer(ptrs))转换为char** - 使用完后，必须遍历释放每个
C.free(unsafe.Pointer(cstr))，最后C.free(unsafe.Pointer(ptrs))
传递 C 结构体数组指针时类型映射易错点
若 C 头文件用 typedef struct { ... } MyStruct; 定义类型，Go 中对应的是 C.MyStruct；若只写 struct MyStruct { ... };，则必须用 C.struct_MyStruct。混用会导致编译错误或运行时崩溃。
立即学习“go语言免费学习笔记（深入）”；
- 错误示例：
C.MyStruct用于未 typedef 的 struct → 编译报undefined: C.MyStruct - 正确做法：检查头文件定义方式，用
go tool cgo -godefs查看生成的 types 文件确认实际映射名 - 数组分配：优先用
C.Cmalloc(C.size_t(n) * C.size_t(unsafe.Sizeof(C.MyStruct{})))，而非make([]C.MyStruct, n)后取地址——后者仍是 Go 分配的内存
NULL 指针传参不是语法问题，而是语义契约
Go 中传 nil 给 C 函数参数，cgo 会自动转成 NULL，但是否安全取决于 C 函数本身是否定义了对 NULL 的处理逻辑。
-
C.strcmp(nil, pcb)会段错误，因strcmp标准行为不接受 NULL -
C.free(nil)是安全的，POSIX 明确允许 - 关键判断：查 C 函数文档或源码，确认其是否声明为 “accepts NULL”；否则必须前置校验并转换为有效指针（如空字符串用
C.CString("")）
真正容易被忽略的不是怎么写转换代码，而是谁负责哪段内存的生命周期——C.CString 分配的要你 C.free，C 端 malloc 的数组要你 free，而 Go 分配的任何含指针的结构体都不能直接传。一旦混淆，panic 或静默内存泄漏就紧随其后。
