Fiber 框架不支持内置后台任务队列或延时执行，必须借助外部机制实现；直接用 goroutine + time.Sleep 存在任务丢失、goroutine 泄漏、无法跨实例调度及缺乏重试监控等问题；推荐使用 Redis ZSET 等独立队列由消费者执行，仅开发场景可谨慎使用带 context 和 recover 的轻量延时。
Go 的 Fiber 框架本身不提供内置的后台任务队列或延时执行机制——它只是一个轻量级 HTTP 路由器，所有中间件和路由处理默认运行在请求生命周期内（即同步、阻塞、短时）。想实现“后台任务异步延时执行”，必须自行组合外部机制，不能依赖 Fiber 自身。
为什么直接用 goroutine + time.Sleep 不可靠
很多人第一反应是：在路由里起个 goroutine，time.Sleep 后执行逻辑。这在开发环境看似能跑，但上线后极易出问题：
- 服务重启或进程崩溃时，未触发的延时任务直接丢失（无持久化、无重试）
- goroutine 泄漏风险高：若
time.Sleep期间请求上下文已取消，但 goroutine 仍持有闭包变量（如数据库连接、日志句柄），可能引发 panic 或资源耗尽 - 无法跨实例调度：多台服务器部署时，延时任务只会在当前实例执行，无法保证唯一性或负载均衡
- 没有失败重试、死信、监控等生产必需能力
推荐方案：用独立任务队列 + Fiber 触发调度
真正可行的延时后台任务，应与 HTTP 请求解耦。核心思路是：Fiber 负责接收请求并写入任务队列；另一个独立组件（消费者）监听队列并执行。
常用组合：
-
Redis+go-redis+ 延时队列（如使用ZSET存储时间戳为 score 的任务） -
RabbitMQ+delayed-exchange插件（需服务端启用） -
Temporal或Cadence（适合复杂工作流，学习成本高）
最轻量落地示例（Redis ZSET）：
// 写入延时任务（例如 5 秒后发通知）
client := redis.NewClient(&redis.Options{Addr: "localhost:6379"})
at := time.Now().Add(5 * time.Second).Unix()
client.ZAdd(ctx, "delayed_jobs", &redis.Z{Score: float64(at), Member: `{"type":"send_notify","user_id":123}`})
另起一个长期运行的 goroutine 持续轮询 ZRANGEBYSCORE，取出到期任务并执行——这部分完全独立于 Fiber 生命周期。
如果必须在 Fiber 进程内做简单延时（仅限开发/低可靠性场景）
仅建议用于非关键路径、可丢失、单机部署的场景（如调试日志归档、临时缓存刷新）。务必加 context 控制和 recover：
- 用
context.WithTimeout包裹延时逻辑，避免 goroutine 长期滞留 - 在 goroutine 开头立即 defer
recover()，防止 panic 导致整个进程退出 - 避免在闭包中直接引用
*fiber.Ctx，它不可跨 goroutine 安全使用；只传必要参数（如 ID、配置）
示例：
go func(id int, delay time.Duration) {
defer func() { if r := recover(); r != nil { log.Printf("job panic: %v", r) } }()
select {
case <-time.After(delay):
// 执行实际逻辑，如 db.Exec(...)
}
}(userID, 3*time.Second)
真正需要可靠延时执行的后台任务，永远不要把它塞进 HTTP 请求处理链路里。Fiber 只该负责“接住请求、快速响应、丢进队列”，剩下的交给专有任务系统。这点容易被忽略，但恰恰是线上稳定性的分水岭。
