rate.limiter未拦截错误是因为它默认不抛异常，仅返回布尔值或阻塞；必须显式检查allow()返回值或reserve().ok()结果，否则限流失效。
Go 的 rate.Limiter 为什么没拦住错误？
因为 rate.Limiter 默认不抛异常，它只返回布尔值或阻塞——你没检查 Allow() 返回值，或没处理 Reserve() 的 OK 字段，错误就静默穿过去了。
-
Allow()立即返回bool，不报错也不 panic，用错就等于没限流 -
Reserve()返回*rate.Reservation，必须调用OK()判断是否被允许，否则即使被限流也会继续执行 - 常见误用：把
limiter.Allow()当作“成功执行”的信号，其实它只是“此刻允许”，和业务逻辑是否出错完全无关
RateLimit 触发时，怎么让 HTTP 接口返回 429？
得手动拦截 + 显式响应，rate.Limiter 不会自动改状态码。
- 在 handler 开头调用
limiter.Allow()或limiter.Reserve().OK() - 如果返回
false，立刻写入w.WriteHeader(http.StatusTooManyRequests)并返回，别走后续逻辑 - 注意：不要在中间件里对所有路径统一限流，比如
/health被拦住会导致 k8s 探针失败 - 示例：
if !limiter.Allow() { http.Error(w, "too many requests", http.StatusTooManyRequests) return }
并发场景下 rate.Limiter 共享实例的坑
共享没问题，但必须确保它是包级变量或单例，而不是每次请求 new 一个。
- 在 handler 里
new(rate.Limiter)→ 每次都是全新令牌桶，完全失效 - 跨 goroutine 使用同一个
*rate.Limiter是安全的（内部用原子操作），无需额外加锁 - 如果按用户 ID 分桶，别用 map + mutex，改用
sync.Map或带 TTL 的 LRU cache，否则高并发下 map 写冲突 panic - 配置示例：
rate.NewLimiter(rate.Every(1*time.Second), 5)表示每秒最多 5 次，不是“每 200ms 一次”
为什么 Reserve() 后没等 Delay() 就执行了？
因为 Reservation.Delay() 是建议等待时间，你不 time.Sleep() 或 time.AfterFunc()，它不会自动生效。
-
Reserve()只是预占令牌，返回的Delay()是“如果现在执行，建议等多久”，不 sleep 就立刻跑 - 真正要实现“匀速执行”，得显式 sleep：
r := limiter.Reserve() if !r.OK() { http.Error(w, "rejected", http.StatusTooManyRequests) return } time.Sleep(r.Delay()) // ⚠️ 这行不能少 - HTTP handler 里 sleep 会阻塞 goroutine，生产环境更推荐用
AllowN(time.Now(), n)做批量判断，避免阻塞
http_status="429" 和 http_status="500"，否则告警一响，你根本分不清是被刷爆了，还是数据库挂了。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
