应避免直接用time.Ticker或time.AfterFunc实现生产级定时调度，因其存在单goroutine阻塞、panic导致任务丢失、无法动态增删三大缺陷；需用container/heap构建优先级队列，配合worker pool、recover机制与指数退避重试。

别用 time.Ticker 做任务调度器

直接用 time.Ticker 或 time.AfterFunc 启动后台任务，上线后大概率出问题：单 goroutine 阻塞、panic 导致整个调度循环退出、无法动态增删任务。这不是“小毛病”，而是架构级缺陷——它让调度器失去可观测性和可控性。

• time.AfterFunc 只执行一次，失败就丢了，没重试、没状态记录
• time.Ticker 虽能循环，但每次 tick 都在同一个 goroutine 里跑，一个 handler panic 就全挂
• 没有优先级、没有并发控制、没有上下文取消能力，根本没法对接真实业务场景（比如高优告警任务必须插队）

用 container/heap 实现带优先级的待执行队列

Go 标准库的 container/heap 是唯一轻量、无依赖、可精确控制的优先队列方案。自己写排序 slice 或引入第三方堆，反而增加不确定性。

• Less 方法必须先比 Priority（数值越小越高），再比 CreatedAt，否则同优先级任务会饿死
• 每次 heap.Push 或 heap.Pop 后，必须调用 heap.Fix 或 heap.Init，否则堆结构失效，排序乱序
• 不要在 Less 里做 DB 查询或网络调用——它在调度循环里高频执行，任何阻塞都会拖慢整个队列消费速度

worker pool 必须带 recover + 状态回调 + 限流

每个任务裸起 goroutine 是最危险的做法：panic 会杀死进程，无法统计失败率，也没法做熔断或降级。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 固定数量的 worker（通常设为 runtime.NumCPU()），从优先队列取任务，不是每来一个任务就起一个 goroutine
• 每个 worker 开头必须包 defer func() { recover() }()，否则任意 handler panic 都会让该 worker 永久退出
• 任务执行完必须回调状态（如成功/失败/重试），并更新 RetryCount 和下一次 RetryDelay（推荐指数退避：time.Second * time.Duration(1 ）
• 用 chan struct{} 控制并发数，比用 sync.WaitGroup 更适合长期运行的调度器

聚合结果时别依赖 channel 的接收顺序

很多人以为 for range ch 收到的结果顺序和发送顺序一致，其实完全不保证——尤其当 worker 数 > 1 且处理耗时不均时，结果严重错乱。

• 如果输出顺序敏感（比如要按原始索引返回），每个 task 结果必须带 Index int 字段，主协程用预分配切片填入：results[index] = value
• 聚合阶段别用 sync.Map，它对写密集场景性能差；优先用主线程初始化的 map[string]int，worker 发回局部结果，主协程统一合并
• channel 必须带缓冲（大小等于任务总数），否则 sender 可能因 receiver 慢而卡住；更关键的是，必须由独立 goroutine 在 wg.Wait() 后调用 close(ch)，否则 for range 永远阻塞

真正难的不是并发本身，而是让每个 goroutine 知道自己什么时候该停、怎么停、停了之后状态去哪了。调度器不是启动一堆 goroutine 就完事，而是构建一套可中断、可重试、可追溯的生命周期闭环。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！