Go time.Ticker 如何实现可停止的周期任务

需要每隔一段时间刷新缓存、发送心跳或扫描待处理记录时，time.Ticker 很合适；但它只负责“按周期发出时间信号”，不会替你结束 goroutine，也不会等待任务完成。可停止的写法是：把 ticker.C 和 context.Done() 放进同一个 select，收到取消信号后先退出循环，再调用 Stop，最后由调用方等待 goroutine 结束。

周期任务的停止点应该由取消信号决定，而不是靠某个 tick 自己猜测。Stop 负责停止后续 tick；任务是否已经退出，要用 WaitGroup、完成通道或直接等待函数返回来确认。

先把启动和退出边界写清楚

创建 ticker 前先校验周期，避免把零值配置直接传给 time.NewTicker。停止责任应和创建责任放在同一个函数或同一个 worker 内，这样调用方只需要取消 context 并等待返回。

package main

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

func runPeriodic(ctx context.Context, period time.Duration, wg *sync.WaitGroup) error {
	// 配置错误在创建 ticker 前返回，避免 NewTicker 因非正周期 panic。
	if period 

这里的 defer ticker.Stop() 是资源和意图的双重收口：即使未来在循环里增加其他返回路径，也不会忘记停止 ticker。Go 1.23 起垃圾回收器可以回收不再可达的 ticker，但业务停止仍然应该显式调用 Stop，因为它表达的是“不要再产生周期事件”。

用 select 同时接收 tick 和停止信号

不要只写 for range ticker.C 再期待 Stop 让循环自动结束，因为 Stop 不会关闭通道。正确做法是显式监听取消信号。主函数在取消后调用 wg.Wait()，就能把“发出停止请求”和“后台任务已退出”区分开。

func main() {
	ctx, cancel := context.WithCancel(context.Background())
	var wg sync.WaitGroup
	if err := runPeriodic(ctx, 2*time.Second, &wg); err != nil {
		panic(err)
	}

	// 真实服务中这里通常由信号处理器或上层生命周期调用 cancel。
	time.Sleep(5 * time.Second)
	cancel()
	wg.Wait() // 等待 worker 完成最后的退出路径。
	fmt.Println("periodic task stopped")
}

如果任务正在一次执行中，取消信号只能让 worker 在下一次检查 ctx.Done() 时退出。想让单次任务也能及时停止，就把同一个 context 继续传给数据库、HTTP 请求或内部循环，而不是只在 ticker 外层监听一次。

慢任务不会自动补齐每个周期

官方文档说明，接收者处理得慢时，ticker 会调整时间间隔或丢弃 tick。因此它不是可靠的任务队列：如果刷新操作偶尔耗时 8 秒、周期却是 5 秒，不能按收到的次数推断“每 5 秒一定执行过一次”。对缓存刷新这类任务，串行执行通常更安全；对可并发的采集任务，则要增加并发上限和取消逻辑。

几个容易误判的边界

Reset 会停止 ticker 并设置新的周期，下一次 tick 会在新周期之后到达；如果多个 goroutine 同时重置同一个 ticker，应把重置动作集中到拥有它的 worker。不要在外部直接关闭 ticker.C，这个通道不是调用方拥有的。

相关问题

调用 Stop 后为什么 range 还不退出？因为 Stop 不关闭 ticker.C，请用 context、done 通道或其他退出条件。

周期任务是否一定按固定次数执行？不一定。接收处理慢时 tick 可能被调整或丢弃；需要补偿的业务应使用队列或持久化调度。

Stop 后还需要等待吗？需要。Stop 只停止后续 tick，不代表正在执行的任务和 goroutine 已经结束。