Go中无面向对象式回调方法，仅支持函数值或接口；传方法需闭包包装或显式转换；应定义命名函数类型（如OnCompleteFunc）、避免nil调用、注意panic恢复与错误处理。
Go 里没有“回调方法”这个概念，只有函数值和接口
Go 不支持像 Java 或 C# 那样的“方法回调”（即绑定到某个实例的、可作为回调传入的成员方法）。你真正能传递的，只有 func 类型的函数值，或实现了某接口的类型。所谓“回调”，在 Go 中就是把一个函数变量传给另一个函数，让它在合适时机调用——本质是高阶函数，不是面向对象的回调机制。
常见误解是想直接传 obj.DoSomething 这种带接收者的方法名，但这是非法的：Go 不允许直接取方法的地址（除非显式转换为函数值）。
- 正确做法是用闭包包装：
func() { obj.DoSomething() } - 或显式构造函数值：
(func())(obj.DoSomething)（仅适用于无参数无返回的指针方法，且obj必须是地址） - 更推荐的是定义明确的函数类型，让调用方传符合签名的函数
用函数类型定义清晰的回调签名
硬写 func() 或 func(string, error) 容易出错且难维护。应该先定义命名函数类型，既提高可读性，也方便约束实现。
type OnCompleteFunc func(result string, err error) type HTTPHandlerFunc func(*http.Request) *http.Response
这样你在函数参数里写 onDone OnCompleteFunc，就比裸写 func(string, error) 更安全、更易搜索、更利于 mock 测试。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 函数类型名建议以
Func结尾，符合 Go 社区惯例（如http.HandlerFunc） - 避免在函数类型中嵌套复杂结构体；如果回调需要传很多参数，考虑封装为结构体 + 方法
- 注意参数顺序：错误通常放最后（
func(data []byte, err error)），与标准库保持一致
传方法时必须显式转成函数值或用闭包
假设你有个结构体 Service 和它的方法 HandleEvent，想把它当回调传给 RegisterHandler：
type Service struct{ id int }
func (s *Service) HandleEvent(msg string) { /* ... */ }
<p>func RegisterHandler(f func(string)) { /<em> ... </em>/ }
下面这些写法中，只有后两种合法：
- ❌ 错误：
RegisterHandler(s.HandleEvent)—— 编译报错：cannot use s.HandleEvent (type func(string)) as type func(string) in argument to RegisterHandler（实际报错更绕，因方法值隐式转换规则限制） - ✅ 正确（闭包）：
RegisterHandler(func(m string) { s.HandleEvent(m) }) - ✅ 正确（显式转换，需取地址）：
RegisterHandler((*Service).HandleEvent) // 但此时第一个参数必须是 *Service，所以通常要配合bind逻辑，不推荐
绝大多数情况下，闭包是最自然、最不容易出错的选择——它自动捕获接收者，语义清晰，且兼容值接收者和指针接收者。
回调执行时的 panic 和错误处理容易被忽略
Go 的函数值回调一旦 panic，若调用方没 recover，整个 goroutine 就崩溃。而标准库（如 http.Serve、time.AfterFunc）多数会 recover 并记录日志，但你自己写的调度逻辑往往不会。
- 如果你提供一个注册回调的 API（比如
OnDataReady(func(...))），务必在内部用defer/recover包裹回调调用 - 不要假设回调一定成功；对关键路径，考虑加超时控制或上下文取消（
ctx.Done()检查） - 避免在回调里启动无限循环或阻塞 IO；回调应轻量，重逻辑建议发消息到 channel 或投递到 worker pool
最常被跳过的细节是：没人检查回调函数是否为 nil。传入 nil 后直接调用会 panic，所以执行前总要加 if f != nil { f(...) }。
