Go ticker 阻塞读取时怎么配合 context 取消

Go 里最稳妥的定时循环写法，不是单独阻塞读取 ，而是把 ticker.C 和 ctx.Done() 放进同一个 select。收到取消信号后先停止 ticker，再让正在执行的业务拿到同一个 context 自己返回；如果业务可能卡在网络或数据库调用中，还必须使用支持 context 的 API。这样才能同时解决“等待下一次 tick 退不出来”和“worker 已经泄漏”的两个问题。

先确认阻塞点在 ticker 还是业务处理

常见问题是循环写成 for range ticker.C，然后在别处调用取消函数。取消 context 并不会让这条单独的接收语句自动变成可退出结构；循环仍然只认识 ticker 通道。改成 select 后，等待 tick 的位置就有了明确的取消分支。

func run(ctx context.Context, interval time.Duration) {
    ticker := time.NewTicker(interval)
    defer ticker.Stop() // 函数离开时停止后续 tick

    for {
        select {
        case 

这里的关键不是 Stop 去“唤醒”接收，而是 ctx.Done() 提供了另一个可被 select 选择的分支。NewTicker 的周期必须大于零；如果处理速度慢于周期，ticker 会调整间隔或丢弃 tick，因此它不是消息队列，也不保证每个时间点都补发。

把取消信号传进每次业务处理

外层循环能退出，只说明“下一轮不再开始”，不代表当前的 handleOnce 已经结束。如果一次任务包含 HTTP 请求、数据库查询、重试退避或向下游发送数据，函数签名应接收 context，并把它传到对应调用链。

func handleOnce(ctx context.Context) error {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, "https://api.example.test/health", nil)
    if err != nil {
        return err // 请求构造失败时直接交给上层判断
    }

    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        return err // context 取消时这里会尽快返回错误
    }
    defer resp.Body.Close() // 每轮请求都关闭响应体

    if resp.StatusCode != http.StatusOK {
        return fmt.Errorf("健康检查状态码: %s", resp.Status)
    }
    return nil
}

不要把 context 只当作外层循环的开关。对于不支持 context 的第三方函数，可以把它放在独立 worker 中，再用结果通道和取消分支管理等待，但要确认该函数最终会返回；仅仅调用 cancel() 并不能强行终止一个不响应取消的同步调用。

停止 ticker 并等待 worker 收尾

如果定时任务由 goroutine 执行，退出路径要同时处理 ticker 和 worker。一个实用的判断表如下：

调用方如果需要确认 worker 已经退出，可以在 goroutine 中 wg.Done()，取消后调用 wg.Wait()。这一步是等待业务收尾，不是等待 cancel 生效；二者的职责不要混在一起。

停止、复用和清理要分开判断

Stop 用于结束当前 ticker，Reset 用于在同一个 ticker 上停止旧周期并设置新周期，二者都要求周期大于零。Stop 不关闭 C，所以不能写出“读通道返回零值就退出”的逻辑；对于同一生命周期内的周期变化，保持 ticker 引用并调用 Reset 更清楚，完全结束后则让 defer ticker.Stop() 兜底。

func restartTicker(ticker *time.Ticker, interval time.Duration) {
    if interval 

退出前的四项复查

• 等待 tick 的 select 同时包含 ctx.Done() 和 ticker.C。
• 每次任务的阻塞调用都能接收 context，或有明确的替代收尾机制。
• ticker 创建后有唯一的停止责任，重复配置不会遗留旧实例。
• 需要等待 goroutine 完成时使用 WaitGroup 或结果通道，而不是等待 ticker.C 自己关闭。

相关问题

调用 ticker.Stop 后 ticker.C 会返回什么？

Stop 不关闭通道，也不会再发送新的 tick。循环应由 context、状态变量或其他完成信号退出。

context 取消后当前任务一定马上停止吗？

不一定。取消函数只发出信号，当前任务必须主动检查或调用支持 context 的 API，调用方还要决定是否等待它收尾。

调整周期应该重新 NewTicker 吗？

同一生命周期内只改变周期时可以对现有 ticker 调用 Reset；如果旧任务和新任务属于不同生命周期，先停止旧 ticker，再创建新的实例更容易管理责任。