Go time.Ticker动态调整周期而不丢状态的实现方式

需要在运行中把任务周期从 1 分钟改成 10 秒时，不要重建一套业务状态，也不要让多个 goroutine 同时改 ticker 和游标。更稳妥的做法是：让一个事件循环独占 time.Ticker、当前周期和业务游标，配置更新只通过 channel 进入；收到合法的新周期后调用 ticker.Reset(d)，已有的游标、去重信息和最后执行时间继续留在状态对象里。

time.Ticker动态调周期的关键是保留同一个消费循环

time.NewTicker 创建后会通过 C channel 提供 tick，Reset 会停止当前计时并按新周期重新开始，下一次 tick 要等新周期经过。这个 API 解决的是“什么时候通知”，不是“任务处理到哪一步”。因此，把 cursor、lastRun、去重键或重试次数放在 ticker 里，是职责混淆。

状态不丢的核心不是保存旧的 ticker，而是保存同一个业务状态对象。周期变更只修改调度字段，状态对象仍由同一个事件循环拥有；这样既不需要给每个字段加锁，也不会出现 Reset 已经生效、游标却被旧 goroutine 覆盖的情况。

把周期更新和状态写入交给同一个 goroutine

下面的示例用 periodCh 接收配置变更，用 state 保存任务游标。配置生产者可以来自 HTTP、配置文件或管理命令，但它不直接触碰 ticker。代码中的 work 只接收并返回业务状态，示例刻意把状态转换放在 owner goroutine 内。

package main

import (
    "context"
    "fmt"
    "time"
)

type schedulerState struct {
    cursor int
    lastRun time.Time
}

func run(ctx context.Context, periodCh 

这里的关键有三点。第一，period 只是当前调度参数，state 才是业务进度；第二，Reset 后下一次 tick 按新周期等待，不应把“马上再执行一次”误当成 Reset 的语义；第三，退出时只做一次清理，避免新的配置消息在服务结束后继续写入状态。

新周期、慢任务和连续更新要有明确边界

实际项目通常会遇到四类边界：

还要接受一个事实：ticker 面向的是周期通知，不是可靠消息队列。官方文档说明慢接收者可能导致调整间隔或丢 tick，所以“一个 tick 对应一次业务处理”不能直接当作可靠投递保证。如果每次触发都必须执行，应把待处理任务写入持久队列或状态表，再由 ticker 负责唤醒扫描；如果只关心最新状态，则可以在事件循环中合并过期 tick。

用一张检查清单确认状态真的没有丢

上线前可以按下面顺序复核，而不是只观察日志里“周期已经变了”：

1. 周期更新是否只有一个 owner goroutine 调用 Reset，并在入口拒绝非正值？
2. 游标、最后执行时间和幂等键是否由同一条路径提交，或有明确的持久化边界？
3. 处理时间超过周期时，选择的是串行、跳过、合并还是有界排队？
4. 连续配置更新时，是否知道中间周期会被覆盖，以及最终值从哪里来？
5. 退出时是否先停止配置输入，再保存快照，最后调用 Stop 并等待 owner 返回？

如果任务需要可靠重试、跨进程恢复或严格的每次触发语义，单独使用 time.Ticker 就不够了；应把可靠性放到队列、数据库或专用调度器中，Ticker 只保留“定期检查”的角色。

延伸问答

调用 Ticker.Reset 后还要重新读取 ticker.C 吗？

不需要。Reset 修改的是同一个 ticker 的周期，消费循环仍然读取原来的 ticker.C。不要在每次更新时新建 goroutine 去替换接收逻辑。

Stop 会关闭 ticker.C 吗？

不会。Stop 让 ticker 不再发送 tick，但 channel 不关闭；退出控制应使用 context 或额外的生命周期信号。

能不能在另一个 goroutine 里直接改 cursor？

除非为状态建立完整的同步协议，否则不建议这样做。把配置、tick 和状态交给同一个 owner，通常比给零散字段加锁更容易证明没有旧状态覆盖新状态。

动态调周期为什么仍然可能少执行一次？

因为 ticker 的 tick 不是可靠任务消息；慢接收者可能丢 tick，Reset 也会重新安排下一次到达。需要每次都执行时，先持久化待办任务，再让周期器触发补偿扫描。