go通过函数类型和闭包自然实现回调，适用于轻量单次异步通知；需判空、避免goroutine泄漏、慎用defer混用，并建议回调签名含context.context。
Go 语言本身没有内置的“回调”关键字或语法糖，但通过函数类型（func）和闭包可以自然、安全地实现回调模式——关键不是模仿其他语言的写法，而是理解何时该用、怎么传、怎么避免 panic 或 goroutine 泄漏。
什么时候该用回调，而不是 channel 或 interface？
回调适合轻量、单次、上下文明确的异步通知或钩子注入，比如 HTTP 中间件、定时任务完成通知、文件读取后处理。它比 channel 更轻（无缓冲管理开销），比定义完整 interface 更灵活（无需提前约定方法签名）。
- 用回调：一次性事件响应（如
http.HandleFunc的 handler）、配置式扩展点（如日志库的OnPanic回调） - 别硬套回调：需要多次通信、状态同步、或跨 goroutine 安全传递数据时，优先选
chan或结构体字段 + 方法 - 特别注意：如果回调里启动了新 goroutine，且没做 cancel 控制，容易导致 goroutine 泄漏
如何安全传递和执行回调函数？
Go 的函数是一等公民，可作为参数、返回值、结构体字段。但必须显式检查是否为 nil，否则运行时 panic。
type Processor struct {
onSuccess func(data string)
onError func(err error)
}
func (p *Processor) Process(input string) {
result, err := doSomething(input)
if err != nil {
if p.onError != nil {
p.onError(err) // 必须判空
}
return
}
if p.onSuccess != nil {
p.onSuccess(result)
}
}
- 始终对回调变量做
if fn != nil判断，不假设调用方一定传了 - 避免在回调中直接操作外部可变状态（如全局 map），除非加锁或使用原子操作
- 若回调需访问结构体字段，优先用闭包捕获，而非传指针——更清晰、更难误用
为什么 defer + 回调组合容易出错？
常见误区是把回调塞进 defer，以为能“自动触发”，结果发现执行时机不对，或闭包捕获了错误的变量值。
立即学习“go语言免费学习笔记（深入）”；
-
defer中的回调会在函数 return 前执行，但此时局部变量可能已变更（尤其循环中） - 错误写法：
for _, id := range ids { defer func() { log.Println("done", id) }() // id 总是最后一个值 } - 正确写法：
for _, id := range ids { id := id // 显式复制 defer func() { log.Println("done", id) }() } - 更推荐：把清理逻辑封装成独立函数，显式调用，而非依赖 defer + 回调混用
回调与 context.CancelFunc 配合的典型陷阱
当回调用于异步操作（如数据库查询、HTTP 请求），且主流程支持取消时，回调内部仍可能继续执行，造成资源浪费或竞态。
- 不要只靠
ctx.Done()关闭主流程，还要在回调里检查ctx.Err() - 回调函数签名建议统一含
context.Context参数，例如：func(ctx context.Context, data string) - 若回调本身启动 goroutine，务必用
ctx.WithCancel衍生子 ctx，并在主流程 cancel 后及时退出
回调模式在 Go 里真正难的不是语法，而是厘清执行边界：谁负责生命周期、谁控制并发、谁承担错误传播责任。一旦把这些划清楚，func 类型就足够可靠。
