单纯用go func()在Echo中是假异步：任务易丢失、无重试、并发失控、无法监控；真异步需worker池+缓冲channel或Redis Stream。
单纯用 go func() 启动协程处理任务，在 Echo 框架里不是异步，是“假异步”——主请求返回了，但任务可能根本没执行完、崩溃就丢、重启全清零。真要后台可靠执行，得靠有缓冲 channel + 固定 worker 池，或直接对接 Redis Stream。
为什么不能在 Echo handler 里直接 go sendEmail()
这是最常见也最危险的做法。表面看响应快了，实际埋了一堆雷：
-
r.Body在 handler 返回后会被关闭，goroutine 里再读就 panic - 进程崩溃或
kill -9时，所有正在跑的 goroutine 瞬间消失，任务永久丢失 - 没有重试：邮件服务临时超时？HTTP 请求失败？这个 goroutine 就结束了，没人知道、也不会重来
- 并发失控：QPS 500 时起 500 个 goroutine，调度和内存压力远超预期
- 无法监控：没有队列长度、失败率、平均耗时，出问题只能翻日志盲猜
make(chan Task, N) 缓冲大小怎么设才不卡死也不爆内存
缓冲大小不是拍脑袋定的，它本质是「最大积压容量」，设太小会阻塞生产者（比如 HTTP handler 卡在 taskCh <- t），设太大又浪费内存且掩盖背压问题。
- 按峰值流量预估：例如接口峰值 QPS 是 200，单任务平均处理耗时 0.3s，则理论积压上限 ≈ 200 × 0.3 = 60，
make(chan Task, 100)比较稳妥 - 必须带缓冲：
chan Task（无缓冲）会导致每次提交都阻塞，直到有 worker 取走，完全失去异步意义 - 提交时要用
select防死锁：select { case taskCh <- t: ... default: return errors.New("queue full") }，避免 handler 被拖住 - 别忘了在程序退出前
close(taskCh)，否则 worker 的for t := range taskCh永不退出
worker 必须包 defer func() { recover() }() 吗
必须。而且得放在 for 循环最外层，不是任务函数内部。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
立即学习“go语言免费学习笔记（深入）”；
- 一个任务 panic（比如空指针、除零、Redis 连接超时未判 err）会直接终止整个 goroutine；没 recover 就等于这个 worker 永久下线
- 固定 3 个 worker，挂掉 1 个，吞吐直接掉 1/3，还可能因积压触发其他问题
- recover 后建议打结构化日志：
zerolog.Ctx(ctx).Err(err).Str("task_id", t.ID).Msg("task panic recovered") - 注意：recover 只捕获当前 goroutine 的 panic，不影响其他 worker，这才是“隔离”的关键
什么时候该切到 Redis Stream 而不是死守 channel
当出现以下任一情况，内存队列就该退役了：
- 部署多实例（K8s 多 pod / 多台机器），channel 无法跨进程共享，任务会重复执行或漏执行
- 要求“至少一次”或“精确一次”语义：channel 无 ACK 机制，worker 崩溃=任务丢失；Stream 支持消费者组 +
XACK+XCLAIM - 需要延时任务（如 10 分钟后发通知）：channel 无法原生支持，得自己套
time.AfterFunc，但进程挂了照样丢；Stream 可配合定时器投递，或直接用 Asynq - 运维可观测性需求上升：想查“当前积压多少”“过去一小时失败率”“哪个任务卡了 2 小时”，这些都得靠持久化+外部查询
真正容易被忽略的是：很多团队在单机阶段用 channel 跑得好好的，一上 K8s 就开始丢任务，却还在调 buffer 大小和 worker 数量——问题不在参数，而在模型本身已不适用。
