Go cgo.Handle 删除后 C 端继续使用会怎样

我在给 Go 和 C 之间加异步回调时，最容易踩到的不是句柄怎么创建，而是释放时间：Go 侧已经调用了 h.Delete()，C 侧却还保留着那个整数，下一次回调又把它传了回来。结论很明确：Delete 会让句柄失效，C 端继续使用旧值并不能“复活”它；Go 回调里再调用 Value() 会因为句柄无效而 panic。

官方地址：https://go.dev/pkg/runtime/cgo/

先区分“C 还拿着数值”和“句柄仍然有效”

cgo.Handle 的底层类型是足够容纳指针位模式的整数。它适合把 Go 值映射成一个可在 C 与 Go 之间传递的标识，但这个标识不是永久资源。官方文档给出的生命周期边界是：句柄从 NewHandle 创建起有效，直到程序调用 Delete；Delete 应该等到 C 代码不再持有这个值时再调用。

这两个状态很容易被混在一起：C 结构体里仍有一个非零整数，只能说明旧值还躺在那里，不能说明 Go 运行时的映射还存在。删除后，C 继续把旧整数传回 Go，得到的是一个失效句柄。下面的静态关系图把“C 保存的值”和“Go 侧有效映射”拆开了。

为什么删除后再次 Value 会 panic

Go 侧的回调通常会把 C 传入的整数转换回 cgo.Handle，然后调用 Value 取出原来的 Go 值。只要这个句柄已经被删除，Value 就不再有可返回的关联值，官方行为是 panic；这不是返回 nil，也不是自动创建一个新句柄。

package main

/*
#include 
extern void GoCallback(uintptr_t handle);
*/
import "C"

import (
    "fmt"
    "runtime/cgo"
)

// GoCallback 只接受仍处于有效生命周期内的句柄。
// C 端必须在调用停止并确认不再回传旧值后，Go 侧才能 Delete。
//export GoCallback
func GoCallback(raw C.uintptr_t) {
    h := cgo.Handle(raw)
    value := h.Value().(string) // 句柄已删除时，这里会因 invalid handle 而 panic。
    fmt.Println(value)
}

func createHandle() C.uintptr_t {
    h := cgo.NewHandle("来自 Go 的上下文")
    // 这里不能立刻 Delete：C 端可能还会异步回调并回传 h。
    return C.uintptr_t(h)
}

func releaseHandle(h cgo.Handle) {
    // 只有 C 端停止使用并完成交接后，才允许释放映射。
    h.Delete()
}

因此，真正要修的不是把 Value 包一层“忽略错误”，因为它没有错误返回值；要修的是跨边界的所有权协议。若 panic 穿过导出的 cgo 回调边界，最终表现还会受到回调包装和进程恢复策略影响，不能把它当作一种可靠的业务分支。

把释放责任放到“最后一次回调”之后

我更愿意把生命周期写成一张小表，而不是让某个 goroutine 看到“不用了”就直接删除。C 端可能有事件循环、定时器或工作线程，它们都必须先停止产生回调，再等待已经在途的回调结束。只有这个交接完成，Go 才执行 Delete。

如果 C API 没有“停止并等待”能力，Go 侧就不能把 Delete 当作普通清理动作。可以改造 C 封装，增加停止标志和 join；如果无法改造，就把句柄的释放时间延长到 C 对象真正销毁之后，代价是暂时多占一份 Go 值引用。

重复回调和重复释放怎么排查

遇到偶发 panic 时，我会先记录句柄的创建、停止交接、最后一次回调和删除时刻，重点看是否存在“删除已经完成，C 工作线程才退出”的窗口。不要只打印句柄整数：旧值在 C 里仍然可能看起来完全正常。

回归用例至少覆盖四种情况：正常回调一次后交接；停止后没有新回调；停止同时已有一条回调在途；错误路径重复执行释放。最后一种尤其要单独测，因为 Delete 对无效句柄同样会 panic，靠 defer h.Delete() 叠加多个清理路径并不天然安全。

我的判断标准是：C 的回调源有明确的停止与等待点，Go 侧只保留一个释放责任人，句柄失效后不再进入 Value。这样处理的重点不是“让 panic 看起来不发生”，而是让 C 保存的旧值在协议上失去继续流动的机会。

常见问题

Delete 后 C 端继续传回旧句柄，会返回 nil 吗？

不会。无效句柄调用 Value 的官方行为是 panic，不是返回 nil 或零值。

把旧句柄整数重新转成 cgo.Handle 能恢复吗？

不能。类型转换只恢复整数外形，不会恢复 Go 运行时已经删除的映射。

可以用 recover 包住 Value 来继续跑吗？

不应把它当作生命周期方案。recover 只能处理特定 Go 调用边界内的 panic，不能替代停止 C 回调、等待在途调用和单一释放责任。