go中无回调函数语法，本质是传函数类型值；关键在goroutine生命周期管理、panic防护及context显式检查。需避免闭包捕获、data race和内存泄漏，推荐直接用函数类型而非interface{}，并确保回调参数化而非依赖外部变量。
Go 里没有“回调函数”这个语法概念，只有函数类型和函数值；所谓回调，本质是把 func() 或带参/返回值的函数类型作为参数传入，由被调用方在合适时机执行它。异步通知场景下，关键不是“怎么传”，而是“谁负责 goroutine 生命周期”和“怎么防 panic 泄漏”。
用 func() 类型定义事件处理器接口
别用 interface{} 或自定义结构体包装回调，直接用函数类型更轻量、可读性更强。常见错误是定义成 type EventHandler func(string, error) 却忘了它本身已是类型，后续声明变量或参数时重复加 func 关键字：
- ✅ 正确：
type OnDone func(result string, err error)，然后DoAsync(onDone OnDone) - ❌ 错误：
DoAsync(onDone func(string, error))—— 虽能编译，但失去类型语义，无法统一约束或扩展（比如加 context） - 如果需要支持取消或超时，建议把
context.Context加进函数签名，而不是靠外部 channel 控制
goroutine 启动时机必须由调用方明确控制
很多人以为“传了函数就等于异步”，其实不然。是否起 goroutine，完全取决于你在哪里调用那个函数值。典型陷阱是：在同步函数里直接执行回调，导致阻塞调用方；或在 goroutine 里执行却没做 recover，导致 panic 杀死整个程序。
- 回调执行点必须显式写
go fn(...)，不能依赖库“自动异步” - 所有异步执行的回调都应包裹
defer func() { _ = recover() }()，尤其当回调来自用户代码时 - 若回调需访问共享状态（如 struct 字段），确保该状态在 goroutine 启动前已初始化完成，避免 data race
避免闭包捕获导致的内存泄漏
回调常通过闭包捕获外层变量，比如在循环中为每个任务注册回调：for _, id := range ids { go do(id, func() { fmt.Println(id) }) }。这里所有回调实际共享最后一个 id 值，且只要回调未执行完，整个外层栈帧就无法 GC。
- 解决方法：用局部变量绑定，
for _, id := range ids { id := id; go do(id, func() { fmt.Println(id) }) } - 更安全的做法是把依赖数据作为参数传入回调，而非闭包捕获：
OnDone func(taskID string, result string) - 如果回调长期存活（如注册为全局事件监听器），检查它是否意外持有了大对象指针（如 *http.Request、*bytes.Buffer）
最易被忽略的是回调执行上下文的 cancel 行为 —— 如果主流程已退出，但回调还在等 IO 或 sleep，它仍会执行并可能写入已关闭的 channel 或修改已释放的结构体字段。别假设“传了 context 就万事大吉”，要真正在回调内部检查 ctx.Err() != nil 并提前返回。
