延时任务控制执行时机，延迟加载控制初始化时机；前者用于定时触发业务逻辑，后者用于首次使用时初始化单例资源，二者需分层隔离、不可混用。
Go 程序里延时任务（如 time.AfterFunc、自定义延迟队列）和延迟加载（如 sync.Once 驱动的按需初始化）本质是两类不同目的的“延迟”——前者控制**执行时机**，后者控制**初始化时机**。它们可以共存，但不能互相替代；强行混用反而容易引发竞态、资源泄漏或启动卡顿。
延时任务不是延迟加载的替代方案
有人看到 time.AfterFunc 能“等几秒再干活”，就试图用它来推迟 DB 初始化，比如：
func initDB() {
time.AfterFunc(3*time.Second, func() {
db, _ = sql.Open("mysql", dsn)
_ = db.Ping()
})
}
这会导致严重问题：
- 调用方无法感知初始化是否完成，
db可能为nil或未就绪，后续操作 panic - 没有错误传播路径，连接失败被静默吞掉
- 如果多次调用
initDB()，会注册多个 timer，造成 goroutine 泄漏 - 违背了“按需加载”的核心原则：不是“等时间”，而是“等第一次使用”
真正该用 sync.Once 的地方：单例资源首次访问才初始化
比如配置解析、日志实例、全局缓存客户端——这些资源只要求“首次用时创建一次，之后复用”。sync.Once 是标准解法：
var (
once sync.Once
cfg *Config
)
func GetConfig() *Config {
once.Do(func() {
cfg = parseConfigFromFile() // 可能含 IO、解析、校验
})
return cfg
}
关键点：
-
once.Do内部有原子锁，保证多 goroutine 并发调用也只执行一次 - 函数体里可以安全做阻塞操作（读文件、连 DB），不会拖慢启动，也不影响其他路径
- 调用方无需关心“是否已初始化”，直接用
GetConfig()即可，语义清晰
延时任务该用在哪？明确需要“未来某时刻触发”的业务逻辑
典型场景是消息延迟投递、定时清理、状态超时转换，例如：
- 用户下单后 30 分钟未支付，自动取消订单 → 用
time.AfterFunc或基于time.Timer的任务队列 - 内存中临时 token 5 分钟后过期 → 启动时注册一个 timer，到期后从 map 中删 key
- 批量上报日志前等待最多 1 秒攒批 → 用
time.AfterFunc+ channel 控制 flush 触发时机
注意：这类任务本身不负责“加载资源”，它依赖的资源（如 DB、logger）应通过 sync.Once 或接口工厂提前准备好，而不是在 timer 回调里现场初始化。
协同的关键：分层隔离，各司其职
一个常见且健壮的组合模式是：
- HTTP handler 收到请求 → 调用
GetCacheClient()（内部用sync.Once懒加载 Redis 客户端） - 业务逻辑判断需延迟执行 → 调用
delayQueue.Push(task, time.Now().Add(5*time.Minute)) - 消费者 goroutine 从队列取出 task → 直接使用已就绪的
cacheClient执行操作
这里没有把“加载 client”塞进 timer 回调，也没有让 handler 等待 client 初始化完成——两者完全解耦。最容易被忽略的是：延迟加载的“按需”，必须绑定到**明确的使用入口点**（如函数调用），而不是靠时间或外部信号触发；而延时任务的“延迟”，必须绑定到**确定的时间语义**，而非资源就绪状态。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
