Context 不应存储 rate.Limiter 或令牌状态，因其只读、不可变且不负责状态管理；限流器应作为依赖显式注入，Context 仅传递取消信号。
Context本身不存令牌状态，别往里塞rate.Limiter
很多人想把 rate.Limiter 实例或当前剩余令牌数塞进 context.Context，这是错的。Context 是只读、不可变、跨 goroutine 安全的传递机制，设计上不支持写入状态。你传进去一个 rate.Limiter 指针，多个 goroutine 并发调用 Allow() 或 Reserve() 时，会直接破坏限流器内部计数（rate.Limiter 虽有 mutex，但不是为 Context 生命周期设计的）。更糟的是，Context 可能被 cancel 后复用，而限流器状态还在跑，逻辑就脱钩了。
正确做法：把限流器作为依赖显式传入 handler 或函数
限流器是服务级/路由级资源，应该在初始化阶段创建，然后像数据库连接、配置一样注入到处理逻辑中。Context 只负责传递「是否该终止」这个信号，不背锅状态管理。
常见错误写法：
// ❌ 错误：把 limiter 塞进 context，还试图更新它 ctx = context.WithValue(ctx, limiterKey, limiter) // 后续从 ctx.Value() 取出来调用 Allow() —— 状态混乱、竞争风险高
推荐结构：
- 全局或 per-route 初始化一个
*rate.Limiter，比如http.HandlerFunc外层闭包持有 - handler 内部调用
limiter.Allow()或limiter.Reserve()，再根据结果决定是否继续执行 - 用
ctx.Done()监听超时/cancel，但和限流判断正交处理
需要“带上下文的限流”？用 limiter.ReserveN(ctx, n)
如果你真要结合 Context 控制限流等待行为（比如等不到令牌就提前放弃），唯一合法入口是 rate.Limiter.ReserveN() 的带 ctx 版本（Go 1.23+）或手动包装。
注意点：
-
ReserveN(ctx, n)不是“从 ctx 读令牌”，而是用 ctx 控制「等待令牌释放的阻塞时间」 - 它返回一个
*rate.Reservation，需调用OK()判断是否拿到令牌；若ctx已 cancel，则立即返回失败 - 必须调用
Cancel()或执行Delay()后再OK()，否则令牌不会真正消耗
示例关键片段：
res := limiter.ReserveN(ctx, 1)
if !res.OK() {
http.Error(w, "rate limited", http.StatusTooManyRequests)
return
}
// 尊重 Reservation 的延迟要求（如需精确控制）
if delay := res.Delay(); delay > 0 {
time.Sleep(delay) // 或用 timer + ctx.Done() 做更安全的等待
}
// 此时才真正扣减令牌
并发场景下共享限流器要注意 scope 和粒度
同一个 *rate.Limiter 实例可安全被多个 goroutine 并发调用，但你要想清楚它的作用域：
- 全局限流（如整个服务每秒 100 请求）→ 用单例
limiter - 用户级限流（如每个
user_id每秒 5 请求）→ 必须用 map + sync.Map 缓存 per-key limiter，且注意内存泄漏（加 TTL 或用 LRU） - 路径级限流（如
/api/pay单独限流）→ 按 path 分 key 创建 limiter，别混用
别指望 Context 帮你做 key 路由。提取 key（如从 ctx.Value("user_id")）可以，但查 limiter 映射、新建、清理，都得自己管。
限流器的状态归属很明确：它属于服务生命周期，不是请求生命周期。Context 的角色只是协调取消和超时，强行让它承载令牌计数，等于让快递员兼职记账——送错件是小事，账本乱了才是大问题。
