使用Cgo处理typedef变量遇到的传参问题

我之前在项目里也碰到过类似Cgo和自定义C typedef类型交互的坑，结合你的场景给你几个实用的解决思路：

1. 先明确Cgo对typedef类型的映射规则 #

首先你要清楚，Cgo会把C语言里的typedef类型直接映射成Go中对应的等价类型。比如如果你的C代码是这样定义的：

typedef struct {
    // 椭圆曲线点的相关字段
} ec_point;

// 接收指针的函数（你能正常调用的）
void ec_point_multiply(ec_point* p, const ec_scalar* scalar);
// 接收值的函数（你调用报错的）
void ec_point_print(ec_point p);

那在Go代码里，C.ec_point就是对应C中ec_point结构体的值类型，*C.ec_point则是指针类型。

2. 针对值传递函数的正确调用方式 #

你说能成功创建ec_point变量、调用接收ec_point*的函数，那大概率是你手里的变量是*C.ec_point类型（比如通过C的创建函数返回的指针），这时候直接传给接收值类型的函数自然会报类型不匹配的错误。

解决方法很简单：解引用指针，传递值类型。举个Go代码的例子：

// 假设通过C函数拿到ec_point的指针
pPtr := C.create_ec_point()
defer C.free_ec_point(pPtr) // 记得释放内存

// 调用接收指针的函数（正常工作）
C.ec_point_multiply(pPtr, scalarPtr)

// 调用接收值的函数，需要解引用指针
C.ec_point_print(*pPtr)

这里要注意一个关键点：确保你解引用的指针是有效的——不能是空指针，而且指向的内存是合法的（比如不是已经被释放的内存）。

3. 内存安全的注意事项 #

如果C的值传递函数会在内部保存这个值的引用，那你得确保Go端的变量不会被GC提前回收。这时候可以在调用完函数后加上runtime.KeepAlive(pPtr)，告诉Go的垃圾回收器暂时不要回收这个变量：

import "runtime"

// ...

C.ec_point_print(*pPtr)
runtime.KeepAlive(pPtr) // 防止GC在函数调用后立刻回收pPtr指向的内存

4. 验证Cgo生成的类型（排查疑难情况） #

如果上面的方法还是不行，你可以用Cgo的-godefs参数查看自动生成的Go类型定义，确认ec_point在Go里的真实类型：

go run -godefs your_cgo_file.go > types.go

打开生成的types.go文件，你就能清楚看到C.ec_point到底是值类型还是指针类型的别名，这能帮你快速定位类型不匹配的根源。

内容的提问来源于stack exchange，提问作者Sleeping Shell