Go ticker 通道未消费时为什么不能补齐每次 tick

很多 Go 程序把 time.NewTicker 当成“每隔一段时间产生一条消息”的队列，处理函数一慢，就发现收到的 tick 少于预期。这个现象不是 channel 丢数据的偶发故障，而是 Ticker 的设计语义：它提供的是当前节拍的通知，不是每一次节拍的历史记录。

接收方没有及时消费时，Go 会保留一个可读取的 tick，后续到来的节拍可以被丢弃或调整；如果业务必须补齐每次发生，就应该记录事件或计数，不能只扩大 ticker 通道。

time.Ticker 送的是节拍，不是事件队列

NewTicker(d) 根据时间间隔产生通知，接收端通常这样写：

ticker := time.NewTicker(time.Second)
defer ticker.Stop()

for now := range ticker.C {
	// 中文注释：这里处理的是“现在该检查一次”，不是补放过去的所有节拍。
	_ = now
	checkHealth()
}

如果 checkHealth 偶尔耗时 5 秒，程序恢复后拿到的不是积压的 5 条通知，而是一个仍然有用的“该继续检查了”的信号。对于刷新缓存、采集最新状态、定期探活，这通常正是想要的结果：旧节拍没有独立业务价值。

慢接收者为什么看不到每一次 tick

Go 官方 time 源码将 ticker 的 channel 建为 1 个元素缓冲。定时到点时，运行时尝试把时间值放进去；如果槽位已经被上一个 tick 占用，就不阻塞等待接收者，而是放弃这次发送。这样定时器不会因为业务处理变慢而不断堆积。

因此，“未消费时不能补齐”有两个直接原因：第一，通道保存的是有限的当前通知，不是无限日志；第二，非阻塞发送优先保证计时器继续工作，而不是保证每个时间点都有对应消息。Stop 只负责停止后续发送，也不会关闭 channel，更不会把已经错过的节拍补回来。

先判断业务要的是最新状态还是发生次数

可以用下面的判断快速选型：

一个常见误区是把 make(chan time.Time, 100) 接到 ticker 后面，期待它“补齐”。ticker 自己的发送通道已经在内部创建，外接 channel 只能转发已经收到的通知，不能恢复发送方主动丢弃的节拍。

需要补偿时，用时间或事件记录替代收取次数

如果目标是知道“处理期间理论上跨过了几个周期”，直接比较时间更可靠：

const period = time.Second
last := time.Now()
ticker := time.NewTicker(period)
defer ticker.Stop()

for now := range ticker.C {
	// 中文注释：按经过的时间计算应补偿的周期数，至少执行一次当前检查。
	elapsed := now.Sub(last)
	cycles := int(elapsed / period)
	if cycles 

这里的补偿只适用于“周期次数”本身就是业务输入的场景。若每次发生都代表一个不能丢失的订单或任务，应该在事件产生时写入数据库、消息队列或可靠日志，再由消费者确认处理；不要试图从 Ticker.C 反推已经消失的事件。

常见问题

time.Ticker 会把所有 tick 排队吗？

不会。官方语义允许为慢接收者调整间隔或丢弃 tick，不能把它当作完整事件队列。

把 ticker 的周期调短能避免丢失吗？

不能，处理速度仍慢于节拍时只会更容易落后。周期应根据业务刷新频率设置，不能用来替代可靠队列。

time.Tick 和 time.NewTicker 有什么区别？

time.Tick 只返回 channel，适合不需要停止控制的简单场景；需要显式停止或重置时使用 NewTicker。