Go C 回调进入 Go 时为什么必须保持函数引用

在 cgo 项目里，C 库要求传入 int (*callback)(int)，而 Go 代码手里却是一个函数值，这时不能直接把 Go 函数变量强转成 C 函数指针。原因不是语法不够灵活，而是两套运行时对函数表示、指针和生命周期的约束不同。

正确做法是保留 Go 回调值的引用，把 C 侧可保存的内容限制为导出函数对应的 C 网关或 runtime/cgo.Handle；只有确认 C 侧不会再次回调后，才能释放这份引用。

函数值不能直接变成 C 的函数指针

C 的函数指针描述的是一个遵循 C ABI 的入口地址，例如 int (*callback)(int)。Go 的函数值还携带闭包环境和 Go 运行时信息，而且函数类型属于含 Go 指针的值。cgo 文档因此明确禁止把 Go 函数值直接传给 C。

需要函数指针时，常见结构是“C 函数指针 → C 网关 → //export 的 Go 函数”。网关的地址属于 C 可调用范围，Go 入口则由 cgo 生成对应的桥接符号。这里保持的不是一个可供 C 任意保存的 Go 地址，而是 Go 侧仍能找到目标回调的引用。

/* C 侧只声明网关类型，避免把 Go 函数值当成 C 指针保存。 */
typedef int (*callback_fcn)(int);
int call_go_callback(int value);

/* 供 C 库接收的网关，内部再调用导出的 Go 入口。 */
static inline int invoke_callback(callback_fcn cb, int value) {
    return cb(value);
}

//export call_go_callback
func call_go_callback(value C.int) C.int {
    // 这里再从 Go 侧的注册表或句柄取回真正的回调函数。
    return C.int(dispatch(int(value)))
}

// C 只拿到网关，Go 函数值仍由 Go 运行时管理。
func dispatch(value int) int {
    return value + 1
}

用 cgo.Handle 把“保持引用”变成可传递的句柄

如果 C 库除了函数指针，还需要保存每次注册对应的回调上下文，不要把包含 Go 指针的函数值塞进 void*。更稳妥的方式是 cgo.NewHandle(fn)：它返回一个整数，C 保存整数，回调时把整数带回 Go，再调用 Value()。

下面的示例展示同步注册和回调的核心关系。示例中的 C 代码是操作示意，实际项目仍应把 C 定义拆到合适的源文件，避免导出函数文件的重复定义问题。

package main

/*
#include 

// C 侧只保存 uintptr_t，不保存 Go 函数值或 Go 指针。
extern void goCallback(uintptr_t handle, int value);
static inline void callFromC(uintptr_t handle, int value) {
    // 这个示意函数代表 C 库发起一次同步回调。
    goCallback(handle, value);
}
*/
import "C"

import (
    "fmt"
    "runtime/cgo"
)

//export goCallback
func goCallback(handle C.uintptr_t, value C.int) {
    // 句柄必须有效；类型断言要与注册时存入的函数类型一致。
    fn := cgo.Handle(handle).Value().(func(C.int))
    fn(value)
}

func main() {
    callback := func(value C.int) {
        // 回调函数值由 Handle 保持，C 只接触整数句柄。
        fmt.Println("callback:", int(value))
    }
    handle := cgo.NewHandle(callback)
    C.callFromC(C.uintptr_t(handle), 7)
    // 只有同步回调已经返回，且 C 不再保存句柄时才能删除。
    handle.Delete()
}

释放时机取决于 C 是否还会回调

Handle 的有效期不会因为 Go 代码离开当前函数就自动结束，反过来也不能用 defer handle.Delete() 机械处理所有场景。同步 C API 在调用返回后不再回调，通常可以立即删除；异步 API 则要先停止事件源、注销回调、等待并发回调退出，再删除句柄。

还要留意三类错误：把无效句柄继续传回 Go 会在 Value() 处失败；重复 Delete 会触发运行时错误；C 保存的是指向 Go 内存的指针时，即使旁边还有一个函数引用，也不能绕过 cgo 指针传递规则。

常见问题

为什么保存函数变量还不够？

保存函数变量只能解决 Go 侧的可达性，不能把它变成合法的 C 函数指针。跨边界仍需导出入口或句柄映射。

可以把 cgo.Handle 转成 unsafe.Pointer 吗？

不可以把整数句柄直接强转成 Go 指针。能传整数就传 uintptr_t；只有接口明确要求 void* 时，才按官方示例传递句柄变量的地址，并确保 C 不保存那个 Go 指针。

异步回调什么时候调用 Delete？

在 C 侧完成注销、不会再发起回调，并且已经等待正在执行的回调结束之后调用。把删除动作绑定到 Go 包装函数返回并不适用于异步库。

判断这类问题时，可以先画出“C 保存的值”和“Go 保持的值”两条线：前者只能是 C 入口或整数句柄，后者负责找到真正的回调函数；两条线的结束时间都确认后，再做释放。