rate.Limiter实现老旧API阶梯式限流需动态收缩burst：按版本用sync.RWMutex保护的map分设Limiter，v1初始burst设为历史P95并发量1.2倍并每周减1，配合Wait(ctx)与超时控制、行为识别降级及独立开关管理。
老旧 API 版本不该一刀切禁用，而应通过阶梯式限流 + 有条件降级逐步收口——核心是让 v1 接口在流量、错误、调用量三个维度上“自然退场”，而非突然失效。
rate.Limiter 怎么配 burst 才能实现“温和衰减”
直接用 rate.NewLimiter(rate.Every(time.Second), 5) 是静态限流，对老旧版本不友好。要阶梯式衰减，得让 burst 值随时间或请求特征动态收缩：
- 按版本号做分流限流：用 map 存不同版本的
Limiter，v1 的 burst 每周减 1（如从 20→19→18），v2 保持不变；注意 map 访问需加sync.RWMutex - burst 不代表“允许突发”，而是“排队缓冲区大小”——设太小（如 burst=1）会导致稍有抖动就 429；设太大（如 burst=100）会让限流形同虚设；建议 v1 初始 burst 设为历史 P95 并发量的 1.2 倍，再逐步下调
- 别只靠
Allow()判定：老旧接口往往延迟高，用Wait(ctx)更合理，但必须传入带超时的 context（如context.WithTimeout(ctx, 300*time.Millisecond)），否则排队会拖垮整体响应
怎么识别并拦截“v1 接口的非必要调用”
单纯看 Accept: application/vnd.myapi.v1+json 或 /v1/users 路径不够，很多客户端硬编码了 v1，但实际只读取部分字段——可结合行为做二次过滤：
- 解析请求体或 query 参数，检测是否含已废弃字段（如
user_type字段在 v2 已改为role），命中即打低优先级标签 - 统计 client IP 的 v1 调用占比：若某 IP 90% 请求都是 v1 且无 v2 尝试，可对其限流阈值额外压降 30%
- 在 middleware 中记录
req.Header.Get("User-Agent")，对明确标注 “legacy-android-2.1” 这类 UA 的请求，直接返回301 Moved Permanently+Location: /v2/xxx，比限流更早干预
降级逻辑为什么不能 fallback 到 v2 实现
常见错误是写个 v1Handler，内部调 v2Service.GetUser() 再做字段转换——这等于把 v1 流量全导给 v2，v2 可能因此被打爆：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- v1 降级必须走纯内存路径：比如用
sync.Map预存 v1 格式的兜底用户数据（{"id": 0, "name": "v1_fallback"}），禁止任何网络/DB 调用 - 若必须兼容 v1 响应结构，降级函数里只做字段映射（如把 v2 的
role映射为 v1 的user_type），不查新数据 - 绝对禁止在 v1 降级分支里调
http.Post("https://api/v2/...")—— 主服务挂了，降级链路也雪崩，监控里会看到两个接口同时报错，根本分不清根因
怎么避免“限流没生效，降级又误触发”的双重失效
典型现象：v1 接口错误率飙升，但监控显示限流器 limiter.Allow() 返回 true 次数远高于预期，同时降级日志大量刷屏——说明限流和降级逻辑互相干扰：
- 限流判断必须在降级之前：先过
limiter.Wait()，失败才进降级；如果反过来，先执行主逻辑再判断是否超时，那限流就完全没意义 - 区分“限流拒绝”和“降级返回”：HTTP 状态码要不同——限流用
429 Too Many Requests，降级用200 OK+ body 标明"status": "degraded"，方便前端区分处理 - 降级开关必须独立控制：用
atomic.Bool管理enableV1Degradation，不能和限流器共用一个配置项；上线初期可设为 false，等限流压测稳定后再开启降级
最易被忽略的是时间窗口错位：限流器按秒计数，但业务指标（如错误率）按分钟聚合，导致你看到“当前限流正常”，其实过去 55 秒内已有大量请求在排队等待，下一秒 burst 耗尽就会集中爆发。务必用直方图监控 limiter.Wait() 的延迟分布，而不仅是成功/失败计数。
