cgo 指针规则导致回调崩溃时的边界排查
我第一次遇到 cgo 回调崩溃时，直觉是把问题归到 goroutine 调度或 GC。后来把桥接代码拆开，真正危险的通常是一个更具体的边界：C 代码保存了不能跨调用保存的 Go 指针，或者回调已经发生，但对应的 Go 状态和句柄先被释放了。
官方资料：https://go.dev/src/cmd/cgo/doc.go
排查顺序建议固定为：先看 C 保存了什么，再看回调参数是否含有 Go 指针，最后看句柄、缓冲区和回调注销的释放顺序。只要 C 侧长期保存的是整数句柄或 C 自己分配的缓冲区，问题通常会比直接传 Go 对象更容易收敛。
先把回调崩溃拆成三个边界
在 cgo 文档里，“Go 指针”取决于内存如何分配，而不是指针的静态类型。传给 C 的 Go 指针，只有在指向的 Go 内存满足规则时才安全；C 代码也不能在调用返回后继续保存它，除非这块内存被明确固定并且仍处于固定期。
因此，现场看到崩溃时我会先记下三件事：C 保存的是地址、函数值还是整数；回调参数是数字、C 缓冲区还是含 Go 指针的对象；回调返回前后，哪一边负责释放资源。不要先用 unsafe.Pointer 改写类型，那往往只是把生命周期错误藏得更深。
从零搭一个只保存整数句柄的回调桥
一个小项目可以只做一件事：C 保存一个整数 token，触发回调时把 token 和整数事件传回 Go；Go 再通过 runtime/cgo.Handle 找回自己的状态。这样 C 侧不会持有 Go 的 map、channel、函数值或结构体指针。
package main
/*
#include
// C 侧只保留整数 token，不保存 Go 指针或 Go 函数值。
extern void goEvent(uintptr_t token, int code);
static void trigger_event(uintptr_t token, int code) {
// 回调参数是标量事件，具体状态由 Go 侧通过 token 查回。
goEvent(token, code);
}
*/
import "C"
import (
"fmt"
"runtime/cgo"
)
type session struct {
name string
}
//export goEvent
func goEvent(token C.uintptr_t, code C.int) {
// 回调期间只把整数 token 转回句柄，不把 C 地址伪装成 Go 对象。
handle := cgo.Handle(token)
value, ok := handle.Value().(session)
if !ok {
// 句柄类型不匹配时直接返回，避免把错误继续传入业务层。
return
}
fmt.Printf("%s received %d\n", value.name, int(code))
}
func main() {
// 注册期创建句柄；C 侧只会看到它的整数表示。
handle := cgo.NewHandle(session{name: "worker-a"})
defer handle.Delete() // 确保回调完全结束后再释放 Go 状态。
// C 只通过静态桥函数触发导出的 Go 回调，不保存 Go 函数值。
C.trigger_event(C.uintptr_t(handle), 200)
} 示例的关键不在某个固定的 C 包装写法，而在归属设计：C 只保存 token，Go 负责 token 到状态的映射；事件本身用整数或 C 拥有的字节缓冲区传递。实际项目若采用异步 C 回调，Delete 必须晚于 C 的注销和所有可能到达的回调。
按内存归属排查最容易误判的场景
字符串、切片、接口、map、channel 和函数值都可能让“看起来只是一个指针”的参数携带 Go 指针。同步调用期间，某些 Go 指针参数会被隐式固定到调用返回；但这不等于 C 可以把地址存起来，留给后台线程稍后使用。
如果 C 需要长期持有数据，优先在 C 堆分配并由 C 释放，或把数据复制到 C 缓冲区；如果必须让 Go 内存跨调用保持地址，则要严格管理 runtime.Pinner 的固定与解除固定次数。runtime/cgo.Handle 解决的是“把 Go 值安全地映射给 C”的问题，不是让任意 Go 指针变成 C 指针。
把崩溃现场收敛成一张释放清单
- 确认 C 保存的字段：如果是 Go 地址、Go 函数值或含 Go 指针的结构，先改成整数句柄、C 标量或 C-owned buffer。
- 确认回调是否异步：同步调用返回后可以结束临时固定；异步场景必须有明确的注销、等待和释放顺序。
- 确认句柄是否仍然有效：
cgo.Handle.Delete后再回调，通常就是“状态先释放、回调后到达”的现场。 - 确认 C 缓冲区的所有者：谁分配、谁写入、谁释放，三项责任不要散落在不同 goroutine 或不同语言侧。
- 诊断阶段可保留默认的 cgo 指针检查；不要为了让程序暂时不崩就关闭检查或用
unsafe绕过规则。
我会把“最后一次正常回调”和“第一次异常回调”之间的句柄状态、C 缓冲区地址以及注销时间记录下来。这个时间线比单看 panic 文本更容易判断到底是越界、释放过早，还是跨调用保存了不允许保存的 Go 指针。
常见问题
回调函数能不能直接作为参数传给 C？
Go 函数值不能按普通 C 函数指针的方式直接长期保存。常见做法是通过 cgo 支持的导出回调入口，再用整数句柄把 Go 状态映射回来；具体 C 包装方式要保证声明和定义符合 cgo 的导出限制。
把 Go slice 转成 unsafe.Pointer 就能解决崩溃吗？
不能。转换只改变表达方式，不改变内存归属和生命周期。若 C 会在调用返回后继续使用这块内存，应改为 C-owned buffer，或在明确的固定期内使用满足规则的 Go 内存。
为什么偶发崩溃总像是 goroutine 问题？
异步回调把“调用返回”和“数据仍被使用”分开了，过早释放句柄、解除固定或关闭 C 缓冲区都会呈现为偶发问题。先画出回调生命周期，再判断 goroutine 是否只是把错误的释放时序放大。
总结
cgo 回调崩溃的核心不是记住更多 unsafe.Pointer 写法，而是明确哪一侧拥有内存、C 能保存什么、回调何时结束。把 Go 状态留在 Go 侧，用 runtime/cgo.Handle 传递整数标识，把跨调用数据放到 C-owned buffer，并让注销、等待、Delete 形成完整闭环，通常就能把一个看似随机的崩溃还原成可排查的生命周期问题。
