延迟加载定时任务依赖指按需初始化数据库连接等资源而非启动时急加载，需用sync.Once+懒初始化函数封装，结合time.Ticker在每次tick中安全调用，支持超时控制与失败重试。
延迟加载定时任务依赖是什么意思
不是指“让定时任务晚点执行”，而是指：在真正需要时才初始化任务所依赖的资源（比如数据库连接、HTTP客户端、配置对象），而不是在程序启动时就全部创建好。Go 的 time.Ticker 或 time.AfterFunc 本身不提供依赖管理能力，延迟加载必须由你手动控制依赖的构造时机。
典型场景是：一个定时任务要查数据库，但数据库连接池还没 ready；或者配置还没从远程 etcd 加载完，你就注册了任务，结果第一次执行就 panic。
用 sync.Once + 懒初始化函数封装依赖
最直接的方式是把依赖包装进一个带 sync.Once 的结构体里，确保只初始化一次，且首次调用时才触发。避免在全局变量初始化阶段硬编码依赖构建逻辑。
-
sync.Once保证并发安全，多个 goroutine 同时调用也不会重复初始化 - 不要把依赖声明为包级变量并直接赋值，比如
var db *sql.DB = initDB()—— 这属于“急加载”，违背延迟意图 - 把初始化逻辑收进方法里，例如
func (t *Task) getDB() (*sql.DB, error)，内部用once.Do()控制
示例：
立即学习“go语言免费学习笔记（深入）”；
type Checker struct {
once sync.Once
db *sql.DB
err error
}
<p>func (c <em>Checker) getDB() (</em>sql.DB, error) {
c.once.Do(func() {
c.db, c.err = connectToDB() // 实际初始化逻辑
})
return c.db, c.err
}</p><p>func (c *Checker) Run() {
db, err := c.getDB()
if err != nil {
log.Printf("skip run: %v", err)
return
}
// use db...
}
结合 time.Ticker 在每次 tick 中按需加载
如果任务本身对依赖可用性要求不高（比如可容忍前几次失败），可以直接在 func() {} 闭包里做懒检查。注意别在 ticker 启动前就调用依赖，否则又变回急加载。
- 每次 tick 都调用
getDB()，第一次失败后后续可能成功，适合配置热更新或服务恢复场景 - 若依赖不可恢复（如配置文件路径写错），需加退避或标记永久失败，否则持续打日志
- 避免在
time.Tick循环里反复 new 对象（如每次 new http.Client），应复用
示例：
立即学习“go语言免费学习笔记（深入）”；
ticker := time.NewTicker(30 * time.Second)
go func() {
for range ticker.C {
db, err := checker.getDB()
if err != nil {
log.Printf("db not ready: %v", err)
continue
}
runWithDB(db)
}
}()
用 context 控制依赖初始化超时与取消
有些依赖初始化可能卡住（比如等待 Consul 健康检查通过），不能让它阻塞整个任务启动。用 context.WithTimeout 包一层，给初始化过程设上限。
- 在
getDB()内部用ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) - 把 ctx 传给
connectToDB(ctx)，让底层支持 cancel（比如sql.OpenDB接受context.Context） - 初始化失败后，下次调用仍会重试，除非你额外加状态缓存（如 failedAt time.Time）来限频
关键点：Go 标准库中很多初始化函数（如 redis.NewClient、mongo.Connect）都支持 context.Context，别忽略这个参数。
真正难的不是写个 sync.Once，而是判断哪些依赖该延迟、哪些必须启动即就绪；以及当依赖初始化失败时，要不要跳过本次执行、重试多少次、是否该发告警——这些逻辑不会自动发生，得你一条条补上。
