用 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分钟后开始") } }
defer ticker.Stop()，否则程序退出后 ticker 仍持有 goroutine；若需动态调整间隔，不能直接改 ticker，得 Stop() 后新建。
存储待发送提醒时，优先用内存 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
}
关键点：key 要含业务上下文（如用户 ID + 时间戳），避免冲突；重启即丢失是预期行为——若需持久化，再叠加定期快照到文件或异步落库。
发送通知前务必校验目标有效性，尤其 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
}常见坑：token 缓存没加锁，多 goroutine 并发刷新导致重复请求；错误返回没判断 resp.StatusCode，400/401 被吞掉。
用 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
}
注意：不要用全局 http.Client.Timeout，它无法中断正在写的 TCP 包；必须靠 context 驱动取消。另外，8 秒是经验值——要略小于 ticker 间隔（比如你设 10 秒 tick），否则下一轮会堆积。
提醒服务看似简单，但时间精度、状态一致性、下游容错这三点最容易被跳过测试，上线后才暴露。特别是当从“单机内存版”升级到“多实例+Redis 分布式”时，原来靠 map 和 sync.RWMutex 解决的问题，会全部变成分布式锁和时钟偏移问题。
