Golang实战：通过函数回调实现异步任务通知

Go中函数回调易踩坑，必须确保不访问已关闭的r.Body、不忽略panic、不绕过context取消；HTTP handler中直接传回调会导致body读取失败、任务静默丢失、panic无日志、超时后仍执行。

Go 里用函数回调实现异步任务通知，不是错，但容易踩坑——尤其在 HTTP handler、并发控制、错误传播和上下文生命周期上。真要这么做，必须明确三点：回调函数不能直接访问已关闭的 r.Body，不能忽略 panic，不能绕过 context 取消机制。

HTTP handler 中直接传回调函数会出什么问题

很多人在 http.HandlerFunc 里写 go doSomething(callback)，以为这就是异步。实际会立刻触发以下问题：

• r.Body 在 handler 返回后被标准库自动关闭，goroutine 里再读就是 http: read on closed body
• 回调里如果用了 log 或 database/sql 连接池，可能因进程重启而静默丢任务
• 没做 recover() 的回调 panic 会杀掉 goroutine，且无日志、不可监控
• 无法响应 context.WithTimeout，超时后仍继续执行

怎么安全地传回调函数（仅限极简场景）

只适用于内部工具、CLI 命令或单元测试模拟，不推荐用于 Web 服务。关键约束：

• 回调函数签名必须带 error，例如 type Callback func(result string, err error)
• 调用方必须在 goroutine 内部完成所有 IO，不能依赖外部请求上下文
• 必须显式启动 goroutine 并包裹 defer func() { if r := recover(); r != nil { log.Printf("callback panic: %v", r) } }()
• 示例中不能出现 r.FormValue、r.Header.Get 等依赖请求对象的操作

正确写法：

func asyncOperation(data string, cb Callback) {
    go func() {
        defer func() {
            if r := recover(); r != nil {
                cb("", fmt.Errorf("panic: %v", r))
            }
        }()
        time.Sleep(1 * time.Second)
        cb("done", nil)
    }()
}

为什么 channel 比回调函数更可靠

Go 的设计哲学是“不要通过共享内存来通信，而应通过通信来共享内存”。回调函数本质是共享函数指针 + 隐式状态，channel 则把通信契约显性化：

立即学习“go语言免费学习笔记（深入）”；

• chan TaskResult 天然支持 select 超时、context.Done() 关闭、缓冲控制
• 发送端和接收端解耦：发布者只管 send，订阅者自主决定收不收、何时收、要不要重试
• 避免回调嵌套（callback hell），每个 goroutine 职责单一
• 配合 sync.WaitGroup 或 errgroup.Group 可自然聚合多个异步结果

典型模式：

type TaskResult struct {
    Data string
    Err  error
}
func doAsync() <-chan TaskResult {
    ch := make(chan TaskResult, 1)
    go func() {
        defer close(ch)
        time.Sleep(1 * time.Second)
        ch <- TaskResult{Data: "ok"}
    }()
    return ch
}
// 调用方可 select 或 <-ch

真正生产级的异步通知该怎么做

Webhook 类场景下，“回调”不是函数，而是持久化+投递+消费三阶段：

• 接收层：校验签名后，用 io.ReadAll(r.Body) 读原始字节，立即 w.WriteHeader(http.StatusOK)，不写 body
• 入队层：把业务 ID（如 pay_id）和元信息存进 Redis Stream 或 PostgreSQL，**别塞 raw_body 或密钥**
• 消费层：worker 从队列拉取，查 DB 获取完整上下文，执行业务逻辑，失败则不 XACK，让 Redis 自动重试
• 去重靠 SETNX task_id_ttl 3600，不是靠回调函数是否已注册

函数回调在这里只存在于 worker 内部模块间通信（比如支付成功后发短信），且应封装成 channel + struct，而非裸函数指针。

最常被忽略的是：回调函数本身没有生命周期管理能力，而 channel 可以和 context 绑定，可以 close，可以 buffer 控制背压——这些才是异步通知真正需要的基础设施，不是语法糖。