go中回调函数非惯用法，易致上下文丢失、错误静默、调试困难；应优先用channel+goroutine，如taskresult结构体配带缓冲channel，主流程select控制超时取消。
Go 里用回调函数做异步事件驱动，不是不能用，而是容易掉进上下文丢失、错误静默、调试困难的坑。真要落地，得先明确：这不是 Go 的惯用法，而是妥协方案。
回调函数类型定义必须匹配实际调用场景
定义 type Callback func(data []byte, err error) 看似通用，但实际中常因参数错位或 nil 处理不一致导致 panic。比如 HTTP 响应体为空时传 nil 给 data，而回调里直接 string(data) 就 panic。
- 建议按具体协议拆分类型：如
type HTTPCallback func(statusCode int, body []byte, err error)，避免靠文档约定语义 - 回调签名里别省略
error参数——哪怕业务逻辑“不可能出错”，也要留着，否则后续加校验时会破坏调用方兼容性 - 不要把
context.Context塞进回调参数列表，它不属于结果数据，应在发起方 goroutine 内控制生命周期
goroutine 启动后回调执行前，r.Body 已不可读
在 HTTP handler 中写 go fetch(url, callback) 是典型错误。handler 返回后，r.Body 被关闭，goroutine 里再读就是 http: read on closed response body 或空数据。
- 必须在 handler 内完成
io.ReadAll(r.Body)，把原始字节存到局部变量，再传给 goroutine - 回调函数本身不能访问
*http.Request或http.ResponseWriter，它们不是 goroutine 安全的 - 如果回调要写响应，得提前把
http.ResponseWriter包装成线程安全结构（如带 mutex 的 wrapper），但更推荐改用 channel + 中间层统一处理
回调嵌套导致错误传播断裂
当 A 函数调用 B，B 内部又调用 C 并传入同一回调，一旦 C 出错，B 若没透传 err，A 就收不到真实错误源。常见于封装第三方 SDK 时。
- 每个中间层都必须检查
err != nil并立即调用回调返回，不能只 log 后 silent ignore - 避免在回调里再起 goroutine 调用另一个回调——这会让堆栈完全丢失，
runtime.Caller只能打到最外层 - 调试时发现回调没触发？先查是否在 goroutine 里 panic 了但没 recover，Go 不会自动打印 goroutine panic 日志
channel 比回调更适合 Go 的异步通信
回调函数本质是“推”模型，而 Go 的并发哲学是“拉”：用 chan TaskResult 显式传递结果，主流程用 select 控制超时和取消。
-
make(chan TaskResult, 1)必须带缓冲，否则发送方 goroutine 可能永久阻塞在ch - 务必
defer close(ch)，否则接收方range ch会永远等下去 - 接收方必须配合
ctx.Done()：select { case r := ，不能只等 channel
真正难的不是怎么写回调，而是判断什么时候不该用回调——比如需要链路追踪、上下文超时、可观测性埋点时，硬套回调只会让问题更隐蔽。
