Fiber 框架不支持原生定时任务，必须借助 Go 标准库（如 time.Ticker）或第三方调度器（如 robfig/cron/v3、asynq）实现；所有定时逻辑须脱离 HTTP 生命周期，显式管理 goroutine 生命周期、超时与优雅关闭。
Fiber 框架本身不提供原生定时任务能力，所有定时逻辑必须脱离 HTTP 生命周期，靠 Go 标准库或第三方调度器实现。
为什么不能用 Fiber 的中间件或路由注册定时任务
Fiber 是 HTTP 路由框架，其生命周期绑定在 app.Listen() 启动的事件循环中。一旦没有请求进入，app 实例本身不会主动执行任何代码；你写在 app.Get() 外部的 time.Ticker 或 time.AfterFunc 会随 main goroutine 退出而失效——除非你显式阻塞主 goroutine。
- 常见错误：在
main()里启动 Fiber 后直接 return，导致定时器 goroutine 被静默终止 - 正确做法：用
sync.WaitGroup或select{}阻塞 main，但需确保定时器 goroutine 已启动且可被 cancel - Fiber 的
app.Use()、app.Get()等仅响应 HTTP 请求，无法触发后台周期性逻辑
用 time.Ticker + context.WithCancel 实现可控定时任务
这是最轻量、无依赖的方案，适合简单轮询（如每 5 秒检查一次缓存健康度）。关键点是把 ticker 和 cancel 控制权暴露到全局或结构体字段，避免 goroutine 泄漏。
- 必须用
context.WithCancel(context.Background())创建可取消上下文，否则无法优雅停止 -
time.Ticker应在go func()内启动，且循环中用select监听ctx.Done() - 不要在 ticker 循环里调用阻塞 I/O（如未设超时的 HTTP 请求），否则会卡住整个 ticker
- 示例片段：
var (
ticker *time.Ticker
cancel context.CancelFunc
)
<p>func startHealthCheck() {
ctx, _cancel := context.WithCancel(context.Background())
cancel = <em>cancel
ticker = time.NewTicker(5 * time.Second)
go func() {
defer ticker.Stop()
for {
select {
case <-ticker.C:
// 执行检查逻辑，务必加超时控制
httpCtx, </em> := context.WithTimeout(ctx, 2*time.Second)
resp, err := http.DefaultClient.Get(httpCtx, "<a href="https://www.php.cn/link/1633b2e8d8d39ecaf5fd05fd16b4ffd0">https://www.php.cn/link/1633b2e8d8d39ecaf5fd05fd16b4ffd0</a>")
if err != nil {
log.Printf("health check failed: %v", err)
continue
}
resp.Body.Close()
case <-ctx.Done():
return
}
}
}()
}</p><p>func stopHealthCheck() {
if cancel != nil {
cancel()
}
}
需要复杂调度时，别硬套 Fiber，换 robfig/cron/v3 或 asynq
当任务涉及 cron 表达式（如 "0 0 * * *）、失败重试、持久化、分布式锁等需求，强行用 time.Ticker 维护会迅速失控。此时应引入专业调度库，并注意与 Fiber 进程生命周期对齐。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
robfig/cron/v3是纯内存调度器，轻量但不支持故障恢复；启动后需确保c.Start()被调用，且 main 不退出 -
asynq基于 Redis，支持失败队列、延迟任务、并发控制，适合生产环境；但需额外部署 Redis 并处理连接池生命周期 - 所有外部调度器都应在
app.Shutdown()钩子中显式关闭，例如：app.Server().RegisterOnShutdown(func() { cron.Stop() }) - 避免在 cron job 中直接操作 Fiber 的
ctx或app实例——它们不属于同一执行上下文
协程超时与 panic 恢复必须手动加，Fiber 不帮你兜底
Fiber 的 ctx.Timeout() 只对当前 HTTP 请求有效，对后台 goroutine 完全无效。任何在定时任务里启动的 goroutine，都必须自己管理超时和 recover。
- 每个
go func()内部都要有defer func(){ if r := recover(); r != nil { log.Printf("panic in timer: %v", r) } }() - HTTP 调用必须配
context.WithTimeout，数据库查询必须设Context参数（如db.QueryRowContext(ctx, ...)） - 不要依赖
http.DefaultClient的全局超时——它不生效于 context 控制流，必须显式传参 - 若任务逻辑可能耗时波动大（如第三方 API 响应从 100ms 到 5s），建议用
time.AfterFunc替代time.Ticker，每次执行完再注册下一次，避免任务堆积
真正容易被忽略的是：Fiber 进程退出时，所有未显式关闭的定时器、ticker、cron 实例都会被 OS 强杀，中间状态（如正在写日志、更新 Redis 计数器）无法保证原子性。务必在 os.Interrupt 信号处理和 app.Shutdown 中做完整清理，而不是只依赖 defer。
