time.ticker适用于固定间隔推送，需配合context或done通道防泄漏；突发流量应使用rate.limiter令牌桶；多实例需redis+lua实现分布式限流；失败推送须用指数退避而非立即重试。
用 time.Ticker 控制推送间隔最直接
Go 里没有内置的“限频推送”类型，但 time.Ticker 是最常用、最轻量的实现方式。它适合固定间隔推送（比如每 5 秒发一次消息），且天然协程安全。
常见错误是直接在 for-select 中无条件 ticker.C 接收却不做退出控制，导致 goroutine 泄漏：
// ❌ 错误：没处理 done 通道，无法停止
ticker := time.NewTicker(5 * time.Second)
for range ticker.C {
pushMessage()
}
正确做法是配合 context.Context 或显式 done 通道：
- 用
select同时监听ticker.C和ctx.Done() - 每次推送前检查是否需要跳过（比如业务条件不满足）
- 推送失败时建议暂停本次 tick，而不是盲目重试——避免雪崩
突发流量下要用 token bucket 限流
当推送请求来自外部（如 HTTP API 触发），且频率不固定、可能突发时，time.Ticker 就不够用了。这时候得上令牌桶（token bucket）——Go 生态推荐用 golang.org/x/time/rate.Limiter。
它不是“定时推”，而是“按需推 + 速率兜底”：
-
limiter := rate.NewLimiter(rate.Every(100*time.Millisecond), 3)表示最多每秒 10 次，初始可突增 3 次 - 每次推送前调用
limiter.Wait(ctx)，阻塞直到拿到令牌；或用limiter.Allow()做非阻塞判断 - 注意：如果推送本身耗时长（比如网络 IO），令牌消耗时机要和实际发送对齐，别在排队阶段就扣令牌
典型误用是把 Limiter 放在 handler 外层统一限流，结果不同用户/设备共用一个桶，导致小客户被大客户挤占配额。
多实例部署时 Redis + Lua 是唯一靠谱方案
单机 time.Ticker 或 rate.Limiter 在多实例场景下完全失效——每个实例都按自己节奏推，总频次翻倍甚至失控。
必须引入共享状态。Redis 是最现实的选择，关键不是存数据，而是靠原子操作防并发：
- 用
INCR+EXPIRE组合实现窗口计数（比如“最近 60 秒内最多推 100 次”） - 更稳妥的做法是用 Lua 脚本封装整个逻辑，避免竞态：
redis.Eval(ctx, luaScript, []string{key}, nowUnix, windowSec, maxCount) - 别依赖 Redis 的过期时间做清理——窗口滑动时旧数据必须主动淘汰，否则计数不准
容易忽略的一点：Lua 脚本返回值要校验，比如返回 0 表示被限流，1 表示放行，业务层必须严格区分，不能只看 error 是否为 nil。
推送失败后重试策略比频率控制更关键
很多人花大力气控频，却让失败推送立刻重试，结果反而放大压力。真正的瓶颈往往不在“推得多”，而在“推不成功还硬推”。
- 对临时性失败（如 HTTP 429、503），用指数退避：
time.After(time.Second - 永久性失败（如设备离线、token 过期）应直接丢弃，记日志并告警，别进重试队列
- 重试任务建议走异步队列（如 Redis List + worker），不要在主推送 goroutine 里 sleep —— 否则卡住整个 ticker
最常被绕过的细节：重试时的频率控制要独立于原始推送频率。比如原始是 1qps，重试队列可以设成 0.1qps，避免重试流淹没正常流。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
