time.Timer和time.Ticker是需手动管理生命周期的底层原语，非开箱即用调度器；NewTicker首次触发在interval后而非立即，必须显式Stop()防goroutine泄漏，任务超时会导致tick丢失但goroutine持续运行。
time.Timer 和 time.Ticker 不是“配置项”，而是 Go 标准库中需手动管理生命周期的底层并发原语。它们没有配置文件、不需要 yaml 或 json 设置，直接调用函数创建即可 —— 但正因为太轻量，反而容易用错。
为什么 time.NewTicker 第一次触发不是立刻？
它严格遵循“创建后等待 d 时间才发第一个 time.Time”的语义。比如 time.NewTicker(5 * time.Second)，从 NewTicker 返回那一刻起，5 秒后才收到首个值。
- 误以为“启动即执行” → 实际逻辑延迟 5 秒，可能造成服务冷启动超时
- 想实现“立即执行一次 + 后续每 5 秒一次” → 必须拆成：
time.AfterFunc(0, f)触发首调，再启time.NewTicker(5 * time.Second) - 或用
time.Sleep+for循环模拟，但不推荐（不可中断、不响应context.Context）
time.Ticker.Stop() 必须显式调用，且不能只写在 for range 循环里
time.Ticker 底层会启动一个长期运行的 goroutine 来发送时间信号；如果没调 Stop()，这个 goroutine 就永远不会退出。
- 现象：pprof 查看
runtime.timerproc数量持续上涨，goroutine 泄漏 - 常见错误写法：
for range ticker.C { ... break }→break只跳出循环，ticker还在后台拼命发信号 - 正确做法：变量定义在循环外，循环结束后立刻调
ticker.Stop()；若用defer，确保ticker变量作用域覆盖整个函数 - 配合
context.Context时，select中监听ctx.Done()后，必须紧跟ticker.Stop()
任务耗时超过 time.Ticker 间隔时会发生什么？
time.Ticker 的通道缓冲区长度固定为 1，不节流、不堆积、不重试。一旦接收端没及时读，新 tick 就被丢弃 —— 但底层 goroutine 仍不断尝试发送，CPU 占用悄然升高。
立即学习“go语言免费学习笔记（深入）”；
- 现象：每 5 秒拉一次接口，某次耗时 8 秒 → 下个 tick 到来瞬间又触发，导致并发请求撞上后端限流
- 安全做法：用
sync.Mutex或atomic.Bool控制串行执行；或改用time.AfterFunc+ 递归调用（天然串行） - 别用
time.Sleep替代ticker：精度差、不可中断、无法与 context 配合
time.After 看似简单，但最容易引发内存泄漏
time.After(d) 本质是 time.NewTimer(d).C，但它返回的是一个匿名 Timer 的通道，你无法拿到指针去调 Stop()。
- 场景：在 for 循环中反复调
time.After(1 * time.Second)→ 每次都新建一个无法回收的Timer - 后果：goroutine 和 channel 持续累积，直到程序退出
- 替代方案：需要复用时，用
time.NewTimer+Reset()；仅单次延时且生命周期明确，可用time.AfterFunc
真正复杂的定时调度（如 cron 表达式、跳过节假日、失败重试），time.Timer 和 time.Ticker 都不合适 —— 它们只是基础构件，不是调度器。这类需求应交给 robfig/cron 或 github.com/go-co-op/gocron 等专用库。
