滑动窗口限流需自维护带时间戳队列+sync.RWMutex，按key分桶存于sync.Map，每次请求清理超时记录、追加当前时间戳并检查长度，避免内存暴涨与锁争抢。
Go HTTP 中间件怎么套 RateLimiter（不用第三方库）
直接用 golang.org/x/time/rate 的 Limiter 最省事，但它默认是「令牌桶」，不是滑动窗口。如果业务明确要滑动窗口（比如“1 分钟内最多 100 次”，且时间窗口要实时滚动），就不能直接用 rate.Limiter 套中间件了——它不支持窗口切片、无法查历史请求时间戳。
实操建议：自己维护一个带时间戳的请求记录队列，配合 sync.RWMutex 控制并发读写。
- 每次请求进来，先清理队列里超时的旧记录（比如
time.Now().Add(-1 * time.Minute)之前的） - 再把当前时间戳追加进队列末尾
- 检查队列长度是否超过阈值（如 100）
- 超出就返回
429 Too Many Requests，不执行后续 handler
滑动窗口核心：怎么存请求时间戳才不爆内存
不能无限制往 slice 里 append 时间戳，尤其高并发下可能瞬间积累数万条。得控制数据结构生命周期和增长边界。
常见错误现象：panic: runtime error: makeslice: cap out of range，或者 GC 频繁、内存持续上涨。
- 用
[]time.Time存时间戳没问题，但必须在每次请求时主动裁剪——只保留窗口期内的记录 - 不要用 map 或 struct 包裹时间戳，纯 slice + 游标更轻量；避免为每个请求分配新对象
- 如果 QPS 过万，考虑用 ring buffer（固定长度 slice + head/tail index），避免频繁 realloc
- 注意：
time.Now()调用本身有开销，高频场景可考虑传入 request 的time.Time（比如从 middleware 上下文带入）
并发安全怎么处理：为什么 sync.Mutex 不够用
多个 goroutine 同时访问滑动窗口队列，必须加锁。但只用 sync.Mutex 会卡住所有请求——读多写少场景下，用 sync.RWMutex 更合适。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
使用场景：API 网关、登录接口、短信发送入口等需精确限流的路径。
-
RWMutex.RLock()用于判断是否超限（只读队列长度） -
RWMutex.Lock()只在真正要修改队列时才获取（清理旧记录 + append 新时间戳） - 别在
RLock()里做耗时操作（比如调用time.Since()多次），容易导致写等待堆积 - 测试时用
ab -n 1000 -c 100容易暴露锁竞争，观察 pprof 的 mutex profile
怎么让限流规则支持 per-user / per-IP 动态配置
硬编码窗口大小和周期等于白做。真实系统需要按来源区分策略，比如普通用户 100 次/分钟，VIP 用户 1000 次/分钟，爬虫 IP 直接 5 次/分钟。
参数差异：不能全局共用一个窗口队列，得按 key 分桶。
- key 构建推荐用
fmt.Sprintf("%s:%s", ip, userID)，注意空值处理（如userID == ""时 fallback 到 IP） - 用
sync.Map存 key → *window 结构体指针，避免锁整个 map；但注意sync.Map不支持遍历，过期清理得靠写时触发 - 不要用
map[string]*window+ 全局RWMutex，高并发下读锁争抢严重 - 如果规则来自配置中心（如 etcd），需监听变更并热更新对应 key 的限流参数，而不是重建整个 map
滑动窗口真正的复杂点不在算法，而在如何平衡精度、内存、GC 和并发安全——三个变量一动，另外两个准出问题。尤其是清理旧时间戳这一步，写错位置或漏判边界，就会导致限流失效或误杀。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
