应使用 time.Ticker 实现稳定间隔提醒，因其由 runtime 定时器驱动、精度高、不累积延迟；需显式调用 Stop() 防泄漏；若处理耗时超间隔，tick 会被丢弃，需按需选用 AfterFunc 或带缓冲 channel 方案。
如何用 time.Ticker 实现稳定间隔提醒
直接用 time.Sleep 轮询做提醒，时间漂移严重，尤其在系统负载高或 GC 触发时。正确做法是用 time.Ticker，它由 runtime 定时器驱动，精度更高、调度更可靠。
注意：time.Ticker 不会自动停止，必须显式调用 ticker.Stop()，否则 goroutine 和 timer 会泄漏。
- 初始化时传入的
time.Duration是「理想间隔」，实际触发时间可能略晚（但不会累积） - 若提醒逻辑执行时间 > 间隔（比如耗时 3s 的 HTTP 请求配 1s 提醒），
Tick通道会阻塞，后续 tick 会被丢弃 —— 这是设计行为，不是 bug - 如需「不丢任务」，改用
time.AfterFunc链式重启，或用带缓冲的 channel + 单独 worker goroutine
ticker := time.NewTicker(5 * time.Second)
defer ticker.Stop()
<p>for {
select {
case <-ticker.C:
fmt.Println("提醒：检查邮件")
}
}为什么不能在 for { time.Sleep() } 里直接写提醒逻辑
看似简洁，实则隐藏三类问题：GC STW 导致休眠被拉长、系统时间调整（如 NTP 同步）让 Sleep 提前/延后返回、无法响应退出信号。
更关键的是：这种写法把「调度权」完全交给用户代码，绕过了 Go runtime 的 timer 优化路径（比如合并相近定时器），在高并发提醒场景下资源开销明显上升。
立即学习“go语言免费学习笔记（深入）”；
-
time.Sleep是阻塞当前 goroutine，但不释放 P，可能影响其他 goroutine 调度公平性 - 若休眠期间程序收到
SIGINT，需额外加 channel 监听，逻辑变臃肿 - 没有内置的「错失补偿」机制 —— 比如机器休眠 10 分钟后唤醒，
Ticker仍按原节奏恢复，而Sleep会直接跳过中间所有提醒
goroutine 泄漏的典型场景与防护
提醒程序常伴随长期运行的 goroutine，最容易因 channel 关闭不一致或忘记 stop 而泄漏。常见模式有两类：
- 启动 goroutine 后未绑定生命周期管理（比如没监听
context.Context.Done()） - 用
time.After或time.Tick创建临时 timer，但未在退出前 stop —— 尤其在频繁启停提醒功能时 - 向已关闭的 channel 发送数据（比如提醒结果上报 channel 被提前 close，但 worker 还在 send）
验证是否泄漏：运行时加 GODEBUG=gctrace=1，观察 goroutine 数是否随提醒次数线性增长；或用 pprof/goroutine 快照比对。
本地时区与夏令时对提醒时间的影响
用 time.Now().Hour() == 9 判断「早上 9 点提醒」是危险的 —— 它依赖系统本地时区，且夏令时切换当天可能出现两次或零次匹配。
正确方式是用 time.Location 显式指定时区，并借助 time.Date 构造目标时刻再比较：
loc, _ := time.LoadLocation("Asia/Shanghai")
now := time.Now().In(loc)
target := time.Date(now.Year(), now.Month(), now.Day(), 9, 0, 0, 0, loc)
if now.After(target) && now.Before(target.Add(1 * time.Minute)) {
fmt.Println("该提醒了")
}更健壮的做法是结合 time.Ticker 每分钟检查一次，避免因系统时间跳变导致漏判。别依赖 time.ParseInLocation 解析固定字符串时间 —— 夏令时边界解析结果可能出人意料。
