Go 应优先用 channel + goroutine 而非回调函数；HTTP handler 中禁止直接 go 启动 goroutine，须校验签名、一次性读取 r.Body、写入 Redis/DB 后立即返回 200；推荐用结构体+channel 封装异步结果。
Go 语言里没有“回调函数优先”的设计哲学，真正该用的是 channel + goroutine 的组合，而不是把 func(result string, err error) 当成默认解法。
HTTP handler 中别直接 go doSomething()
很多人在接口里写 go processOrder(r) 就以为完成了异步——这是高危操作。问题包括：
-
r.Body在 handler 返回后会被关闭，goroutine 里再读就是空或 panic - 没做并发控制，突发流量可能打爆内存或数据库连接
- goroutine 内 panic 不会传播到上层，日志里完全看不到
- 进程重启时所有未执行的 goroutine 彻底丢失，任务无声消失
正确做法只有三步：校验签名（如 X-Hub-Signature-256）、io.ReadAll(r.Body) 一次性读完、把任务结构体同步写入 Redis Stream 或 DB，然后立刻返回 200 OK。
用 channel 封装异步结果比回调函数更可控
显式传回调函数容易导致错误传递断裂、上下文丢失、调试困难。推荐用结构体 + channel：
<pre class="brush:php;toolbar:false;">type TaskResult struct {
Data string
Err error
}
func asyncPay(ctx context.Context, orderID string) <p>关键点：</p>
- channel 必须带缓冲（如
make(chan TaskResult, 1)），否则 goroutine 可能永久阻塞 - 务必
close(ch)，避免接收方死等 - 主流程要用
select配合ctx.Done()做超时或取消，不能无脑
Redis Stream 是生产环境异步任务的可靠基座
不用硬上 Kafka，Redis Stream 天然支持消费者组、ACK、重试、死信归档。但必须注意几个动作顺序：
- 启动消费者前先确保组存在：
XGROUP CREATE order_events orders $ MKSTREAM - 拉消息必须用：
XREADGROUP GROUP orders worker-01 COUNT 10 BLOCK 5000 STREAMS order_events >，其中>表示只读新消息 - 业务逻辑成功后才调
XACK；提前 ACK = 消息丢失 - 失败时不
XACK，让 Redis 在TIMEOUT后自动用XCLAIM重新分配 - 幂等性靠
SETNX task_id_ttl 3600实现，失败直接 return
这整套机制的核心不是“怎么起 goroutine”，而是“怎么保证每条消息至少处理一次”。
回调函数只适合极简场景，比如单元测试或 CLI 工具内部链式调用
如果你真要用回调，仅限以下情况：
- 第三方 SDK 强制要求传
func()类型参数 - 命令行工具里做短生命周期的链式操作（如
fetch(url).then(print).catch(log)） - 事件钩子（hook）需要插拔式注册，且不涉及跨 goroutine 状态共享
除此之外，只要涉及错误传播、context 传递、超时控制、可观测性，channel 就是更稳的选择。尤其当多个异步任务要聚合结果时，sync.WaitGroup + 共享 channel 的模式远比嵌套回调清晰。
最常被忽略的一点：无论用 channel 还是回调，都得明确谁负责 recover panic、谁关资源、谁清 context。这些边界不划清，异步代码上线后大概率变成定时炸弹。
