Golang实现定时提醒通知功能实践

用 time.Ticker 实现轻量级定时提醒，避免 time.AfterFunc 循环调用导致 goroutine 泄漏和时间漂移；配合内存 map + sync.RWMutex 存储提醒项，前置校验 token 有效性，并用 context.WithTimeout 控制单次发送超时。

用 time.Ticker 实现轻量级定时提醒，别碰 time.AfterFunc 做循环

频繁调用 time.AfterFunc 模拟周期任务会导致 goroutine 泄漏和时间漂移——它只触发一次，手动递归调用又难控制生命周期。真正适合提醒场景的是 time.Ticker：

ticker := time.NewTicker(10 * time.Second)
defer ticker.Stop()
for {
select {
case <-ticker.C:
sendReminder("会议将在5分钟后开始")
}
}

存储待发送提醒时，优先用内存 map + sync.RWMutex，而非立刻上数据库

基础提醒功能（如用户登录后 3 分钟弹窗、每日早 9 点推送天气）并发不高、数据量小，硬上 MySQL 或 Redis 反而增加延迟和运维负担。一个带读写锁的内存结构更可控：

type ReminderStore struct {
    mu sync.RWMutex
    items map[string]*Reminder // key: "user123:202512290900"
}
func (s ReminderStore) Add(r Reminder) {
s.mu.Lock()
defer s.mu.Unlock()
s.items[r.Key()] = r
}
func (s ReminderStore) Get(key string) (Reminder, bool) {
s.mu.RLock()
defer s.mu.RUnlock()
r, ok := s.items[key]
return r, ok
}

发送通知前务必校验目标有效性，尤其 HTTP 推送易因 token 过期静默失败

很多提醒服务在 sendReminder() 里直接调 http.Post，但企业微信/钉钉/飞书的 access_token 通常 2 小时过期，不校验就发不出去，且无错误日志。正确做法是把认证逻辑前置：

func sendReminder(msg string) error {
    token, err := getValidAccessToken() // 内部检查缓存+自动刷新
    if err != nil {
        return fmt.Errorf("failed to get access token: %w", err)
    }
payload := map[string]interface{}{
    "msgtype": "text",
    "text": map[string]string{"content": msg},
}
_, err = http.Post("https://qyapi.weixin.qq.com/...?access_token="+token,
    "application/json", bytes.NewBuffer(payloadBytes))
return err
}

用 context.WithTimeout 控制单次提醒生命周期，防止卡死阻塞整个 ticker

网络抖动、下游服务不可用时，http.Post 可能 hang 住几十秒，拖垮整个 ticker 循环。必须为每次发送设置超时：

ctx, cancel := context.WithTimeout(context.Background(), 8*time.Second)
defer cancel()
req, _ := http.NewRequestWithContext(ctx, "POST", url, body)
resp, err := http.DefaultClient.Do(req)
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
log.Printf("reminder timeout for %s", url)
}
return err
}

提醒服务看似简单，但时间精度、状态一致性、下游容错这三点最容易被跳过测试，上线后才暴露。特别是当从“单机内存版”升级到“多实例+Redis 分布式”时，原来靠 map 和 sync.RWMutex 解决的问题，会全部变成分布式锁和时钟偏移问题。