滑动窗口限流不能只用time.Now().Unix()分桶，因其秒级精度导致窗口边界突变，使相邻毫秒请求被分入不同桶而阈值翻倍；必须用UnixMilli()对齐毫秒、动态加权累加，并避免sync.Map改用环形缓冲区+atomic。
滑动窗口限流为什么不能只用 time.Now().Unix() 做分桶？
因为 time.Now().Unix() 取的是秒级时间戳，直接按秒切桶会导致窗口边界突变——比如请求集中在 12:00:59.999 和 12:01:00.001，实际只差 2ms，却被分到两个桶里，限流阈值瞬间翻倍。滑动窗口的核心是「按毫秒对齐 + 加权累加」，不是简单丢弃旧桶。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
time.Now().UnixMilli()获取毫秒时间戳，作为窗口移动的基准 - 窗口长度（如 1 秒）必须转为毫秒参与计算：
windowMs := int64(1000) - 每个请求要同时写入「当前毫秒桶」和「上一个桶」，并按剩余毫秒比例加权：当前桶权重 = (nowMs % windowMs) / windowMs
- 不推荐手写哈希映射桶数组——Go 的
sync.Map在高频读写下有锁竞争，改用固定长度环形缓冲区 +atomic更稳
如何用 sync.Pool 避免频繁创建滑动窗口结构体？
每次 HTTP 请求都 new 一个限流器对象会触发 GC 压力，尤其在 QPS > 1k 场景下。滑动窗口本身状态少（主要是桶数组和原子计数器），适合复用。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 定义池子时指定
New函数返回初始化好的结构体：var windowPool = sync.Pool{New: func() any { return &SlidingWindow{buckets: make([]int64, 1000), ...}}} - 获取后必须重置内部状态（如清空桶、重置原子变量），不能依赖构造函数——
sync.Pool不保证返回对象干净 - 避免把
context.Context或 handler 参数塞进结构体里复用，容易引发数据污染 - 如果窗口大小动态可配（如 per-route 不同限流值），池子就得按配置维度拆分，否则复用会出错
令牌桶和滑动窗口在 Go 中的实际性能差异在哪？
很多人以为滑动窗口更“精确”，但实测在 10k QPS 下，纯内存滑动窗口比 golang.org/x/time/rate.Limiter（令牌桶）慢 15%~20%，主因是每次请求都要做两次原子加法 + 一次除法 + 条件分支判断。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 如果业务能接受「1 秒内允许突发 2× 限流值」（比如限 100qps，允许某秒打 200 次），直接用
rate.NewLimiter更省心 - 真需要严格滑动窗口时，把桶数量设为窗口毫秒数（如 1s 窗口 → 1000 个桶），但注意
make([]int64, 1000)本身就有 8KB 内存开销，别盲目设成 10000 - 高并发下优先用
unsafe.Pointer+ CAS 替代atomic.AddInt64对单个桶操作，但需确保编译器不会重排指令——Go 1.22+ 的atomic.Int64已足够安全，不建议过早优化
HTTP middleware 中如何避免 context 超时导致限流误判？
常见错误是把限流逻辑放在 ctx, cancel := context.WithTimeout(r.Context(), 100*time.Millisecond) 之后，结果请求还没走到限流就超时了，但限流计数已增加，造成漏限或误限。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 限流必须在 middleware 最开头执行，且完全不依赖
r.Context()——用time.Now()和本地变量就够了 - 如果要结合用户 ID 做分布式限流，
userID必须从 header 或 token 解析，不能等后续中间件（如 auth）注入到 context 里再取 - 记录日志时别打
ctx.Err()判断是否超时——此时限流已生效，该打的是「rejected by rate limit」而非 timeout - 测试时用
httptest.NewRequest("GET", "/", nil).WithContext(context.Background())，确保 context 干净
滑动窗口最难的不是算术，是让每个桶的生命周期和 GC 友好性、并发安全性、上下文无关性同时成立。多数人卡在「以为只要数学对就行」，其实 Go runtime 的内存模型和调度特性才是真正的门槛。
