Go中回调函数非首选，goroutine+channel更自然；仅对接C库等必要场景才用，需注意C兼容性与线程安全；推荐channel+closure替代方案，支持context取消与错误处理。
回调函数在 Go 中不是原生异步模型的首选
Go 本身不鼓励用回调函数处理异步事件——goroutine + channel 是更自然、更可控的方式。强行模拟 JavaScript 风格的回调（比如传 func(err error, result interface{})）容易导致错误传播混乱、上下文丢失、panic 捕获困难，且无法利用 select 等语言特性做超时或取消。
什么时候真需要回调？比如对接 C 库或遗留系统
当你必须调用 C.goCall、syscall 或某些封装了回调注册机制的第三方 SDK（如某些硬件驱动、音视频 SDK）时，Go 允许你把 Go 函数转成 C 可调用的函数指针，但要注意：
- 回调函数必须标记为
//export MyCallback，且签名只能含 C 兼容类型（*C.int、C.long等），不能直接传 Go 的error或struct - 回调里不能直接调用 Go 运行时（如
fmt.Println、panic、channel send），否则可能 crash；需通过runtime.LockOSThread()或go func() { ... }()转回 Go 线程安全上下文 - 若回调需访问 Go 对象，得用
C.uintptr_t+unsafe.Pointer手动传参并转换，极易出错
更安全的“类回调”替代方案：channel + closure
多数场景下，你可以用闭包捕获变量 + channel 通知来模拟回调语义，既保持可读性，又避免 C 交互风险：
func DoAsyncWork(done chan<- bool, onSuccess func(string), onError func(error)) {
go func() {
defer func() {
if r := recover(); r != nil {
onError(fmt.Errorf("panic: %v", r))
}
}()
result, err := heavyWork()
if err != nil {
onError(err)
} else {
onSuccess(result)
}
done <- true
}()
}调用时：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
done := make(chan bool, 1)
DoAsyncWork(done,
func(s string) { log.Println("success:", s) },
func(e error) { log.Println("fail:", e) })
<-done // 等待完成（可选）这种写法保留了回调的“逻辑分片”感，同时所有执行都在 Go runtime 内，支持 context.Context 取消、defer 清理、标准错误处理。
别忽略 goroutine 泄漏和 context 取消
哪怕用了 channel 封装，如果异步操作本身不可取消（比如没带 context.Context 参数的阻塞 I/O），或者回调函数里忘了关闭 channel、没处理 select 默认分支，就很容易堆积 goroutine：
- 所有异步函数建议第一个参数是
ctx context.Context，并在内部用select { case - 回调函数若要发消息到 channel，务必用带缓冲的 channel 或加
select防阻塞，否则 goroutine 卡住不退出 - 不要在回调里启动新 goroutine 后不等待——尤其当它依赖外部资源（如数据库连接池）时，泄漏会更快暴露
真正难的从来不是怎么写回调，而是怎么让它在超时、取消、panic 时依然干净退出。这点 Go 的 channel 和 context 已经提供了足够工具，绕开它们去硬套回调模式，往往得不偿失。
