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 则把通信契约显性化：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“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 控制背压——这些才是异步通知真正需要的基础设施，不是语法糖。
