标准 time.Ticker 不适合复杂任务调度，因其仅定时发信号，不管理任务生命周期、不处理 panic/阻塞/超时，无法动态增删任务，且多任务共用通道易导致堆积或静默丢失；应改用 sync.Map + time.AfterFunc 实现可注册注销的任务池，并结合 context.WithTimeout 和 errgroup.Group 确保超时控制与 goroutine 干净退出。
为什么标准 time.Ticker 不适合复杂任务调度
它只负责“按时发信号”，不管理任务生命周期，也不处理 panic、阻塞或超时。一旦某个 goroutine 挂住或 panic，整个 ticker 循环可能卡死或静默丢失任务。
- 多个任务共用一个
ticker.C时，无法独立启停 - 任务执行时间超过 tick 间隔，会堆积 goroutine（无并发控制）
- 没有错误传播机制，
recover()必须手动加在每处任务里 - 无法动态增删任务，所有逻辑得写死在 for-select 里
用 sync.Map + time.AfterFunc 实现可注册/注销的任务池
避免全局 ticker 压力，每个任务用独立的定时触发，靠 sync.Map 管理活跃句柄，注销时调用 Stop() 清理资源。
type Scheduler struct {
tasks sync.Map // map[string]*time.Timer
}
func (s *Scheduler) Add(name string, delay time.Duration, f func()) {
timer := time.AfterFunc(delay, func() {
defer func() {
if r := recover(); r != nil {
log.Printf("task %s panicked: %v", name, r)
}
}()
f()
s.Add(name, delay, f) // 自动重入（周期任务）
})
s.tasks.Store(name, timer)
}
func (s *Scheduler) Remove(name string) {
if v, ok := s.tasks.Load(name); ok {
if timer, ok := v.(*time.Timer); ok {
timer.Stop()
}
s.tasks.Delete(name)
}
}
-
Add是“一次性+自动重入”模式，适合固定间隔任务；如需单次执行，去掉递归调用即可 -
Remove必须调用timer.Stop()，否则即使删除 key，timer 仍会触发并写入已失效的 map - 任务名（
name）必须唯一，否则后注册的会覆盖前一个
用 context.WithTimeout 控制单个任务执行时长
防止某个任务长期阻塞，拖垮整个调度器。不能只依赖外部超时，要在任务内部主动检查 context。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func withTimeout(ctx context.Context, timeout time.Duration, f func(context.Context)) {
ctx, cancel := context.WithTimeout(ctx, timeout)
defer cancel()
f(ctx)
}
// 使用示例：
sched.Add("fetch-api", 5*time.Second, func() {
withTimeout(context.Background(), 3*time.Second, func(ctx context.Context) {
resp, err := http.DefaultClient.GetContext(ctx, "https://api.example.com")
if err != nil {
if ctx.Err() == context.DeadlineExceeded {
log.Println("fetch-api timed out")
}
return
}
defer resp.Body.Close()
// ...
})
})
- 不要把
context.WithTimeout放在Add外层——那只会限制“启动任务”这一步，不是执行 - 任务函数内必须显式传入
ctx并在 I/O 调用中使用（如http.Client.GetContext），否则超时无效 - 注意：
time.AfterFunc创建的 goroutine 无法被外部 context 取消，所以超时逻辑必须收口到任务内部
goroutine 泄漏的两个隐蔽点
一是未清理的 time.Timer，二是任务中启动了子 goroutine 却没做生命周期绑定。
立即学习“go语言免费学习笔记（深入）”；
- 所有通过
time.NewTimer或time.AfterFunc启动的 timer，只要没调用Stop()或触发过，就一直持有 goroutine 引用 - 任务里用
go func() {...}()启动的子协程，若父任务被Remove，子协程仍在运行且无法感知——必须用context.WithCancel显式传递取消信号 - 建议统一用
errgroup.Group管理子任务，便于等待和传播 cancel
真正难的不是启动一堆 goroutine，而是让它们在该停的时候干净退出。多数调度器崩掉，都是因为某次注销漏掉了一个 timer 或一个 goroutine。
