基础定时器：time.Timer与time.Ticker
Golang标准库的time包提供了两类核心定时器：一次性触发的Timer和周期性触发的Ticker。两者都基于系统底层的小顶堆时间轮实现，但使用场景截然不同。当需要延迟执行某个任务或设置超时控制时，Timer是最轻量的选择。通过time.NewTimer(d)创建一个在d时间后向通道发送当前时间的定时器，配合select语句便可以实现非阻塞的超时逻辑。
实际开发中，定时任务的重复执行依赖的是Ticker。它内部包含一个以固定频率触发的时间通道，调用time.NewTicker(interval)后，每次间隔就会从C通道中读出一个时间点。比如构建一个每隔5秒打印日志的示例：
package main
import (
"fmt"
"time"
)
func main() {
ticker := time.NewTicker(5 * time.Second)
defer ticker.Stop() // 及时释放资源
for range ticker.C {
fmt.Println("执行定时任务:", time.Now().Format("15:04:05"))
}
}
需要特别注意Ticker的泄漏问题。如果不再需要定时器，必须调用Stop()方法，否则它持有的goroutine和底层时间资源不会被回收。在循环中range ticker.C会永久阻塞，通常会在另一个goroutine中监听Done通道来实现安全退出。此外，Ticker的触发不会因为任务执行时间过长而自动延迟——如果任务执行时间超过间隔，下一次触发时上一次可能还未完成，这会导致多个goroutine并发执行同一任务，造成数据竞争。为避免该问题，需要配合sync.Mutex或利用通道自带的阻塞特性进行控制。
time.AfterFunc是另一个被低估的定时工具，它允许在指定延迟后直接在独立goroutine中执行一个函数，适合简单的延迟任务调度。但需注意它返回的*Timer虽然可以提前取消，但如果忘记调用Stop，即便函数已经执行完毕，其底层资源也不会立即释放。在实际项目中，对于需要严格管理生命周期的基础定时任务，建议统一封装Ticker并结合context.Context进行超时和取消控制。
使用cron库实现复杂调度
标准库的定时器只能表达固定间隔，无法满足“每周一上午9点执行报表生成”这类日历级调度需求。业界广泛使用的robfig/cron库完美弥补了这一空缺，它全面兼容Unix cron表达式，并且支持秒级精度和链式配置。安装后引入github.com/robfig/cron/v3，即可快速创建调度器。
cron表达式由六个空格分隔的字段组成，分别表示秒、分、时、日、月、星期。例如0 30 9 * * 1表示每周一9:30:00触发。除了标准规则，cron还提供了预定义宏：@every 5m表示每5分钟执行一次，@daily代表每天午夜。指定时区时可以使用cron.WithLocation(time.UTC)选项，避免服务器时区漂移导致的时间偏差。下面是添加两个不同调度规则任务的代码：
package main
import (
"fmt"
"github.com/robfig/cron/v3"
"time"
)
func main() {
c := cron.New(cron.WithSeconds()) // 启用秒级支持
// 每5秒执行一次
c.AddFunc("@every 5s", func() {
fmt.Println("每5秒任务:", time.Now().Format("15:04:05"))
})
// 每分钟的第30秒执行
c.AddFunc("30 * * * * *", func() {
fmt.Println("固定秒数任务:", time.Now().Format("15:04:05"))
})
c.Start()
// 阻塞主程序，实际项目中可用context或信号量控制退出
select {}
}
cron调度器内部使用goroutine池管理任务执行，默认情况下如果一个任务的执行时间超出触发间隔，下一次触发依然会创建新的goroutine去执行，同样存在并发重叠风险。可以通过cron.WithChain(cron.SkipIfStillRunning(cron.DefaultLogger))添加任务链拦截器，当上一次执行未结束时直接跳过本次触发。如果需要更细粒度的控制，也可以在任务函数内部通过sync.Mutex手动上锁。
另一个常见问题是Panic隔离。在AddFunc中直接封装的函数如果发生panic而未被recover，将导致整个调度进程崩溃。cron库已经内置了恢复机制，默认会捕获并记录panic，不会停止调度器。但如果你需要自定义处理逻辑，可以传入cron.WithChain(cron.Recover(cron.DefaultLogger))或自己实现Job接口并添加defer recover。对业务稳定性来说，这是一道不可或缺的防线。
任务调度器的管理与优雅关闭
实际系统往往需要集中管理数十个定时任务，动态调整调度周期甚至暂停某个任务，这就要求在基础调度之外构建一层任务管理器。最简单的方式是维护一个map，键为任务ID，值为对应的cron.EntryID，并暴露AddJob、RemoveJob、UpdateJob等接口。新增任务时，通过AddFunc或AddJob返回的ID记录在表中；更新任务时，先移除旧ID再添加新ID。需要注意的是，操作cron调度器本身不是并发安全的，所有修改都需要在同一个goroutine中或者通过锁保护。
优雅关闭是生产环境必备的特性。当服务收到终止信号时，不应该暴力中断正在执行的任务，而应等待它们自行结束或超时。在Golang中，可以利用os.Signal监听SIGINT或SIGTERM，然后调用调度器的Stop()方法，该方法会返回一个context.Context，当所有活跃任务完成后该context会被取消。可以直接等待该context的Done()通道，并设置一个最大等待时长避免无限阻塞：
quit := make(chan os.Signal, 1)
signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
<-quit
fmt.Println("正在优雅关闭调度器...")
ctx := c.Stop() // 返回 context
select {
case <-ctx.Done():
fmt.Println("所有任务已退出")
case <-time.After(10 * time.Second):
fmt.Println("等待超时，强制退出")
}
对于任务执行状态的监控，可以在每个任务函数中打入耗时统计或状态变更日志，并暴露一个HTTP接口查看当前有哪些已注册任务、最近一次执行时间和是否失败。这类健康检查有助于快速定位调度异常。结合context的传递，还可以将追踪ID注入到每个任务的日志中，形成全链路观测。总之，Golang原生的并发模型使得构建轻量级、高可控的任务调度系统非常自然，只要对任务重叠、panic恢复、资源释放等细节加以约束，就能获得一个生产可用的定时任务管理模块。