用 time.Tick 原子计数器实现秒级QPS统计每秒tick重置计数器请求入口仅atomic.Add轻量无锁暴露QPS应独立路由避免伪共享rate.Limiter不适用于观测高精度需分桶滑动窗口。用 time.Tick 原子计数器做秒级 QPS 统计实时 QPS 统计不需要高精度时间戳或复杂滑动窗口多数服务场景下“最近 1 秒内请求数”就足够指导限流和告警。直接用 time.Tick 配合 sync/atomic 是最轻量、无锁、低开销的做法。常见错误是用 time.Now() 手动比对时间边界导致每请求都触发条件判断和变量读写压测时原子操作反而成了瓶颈或者误用 time.AfterFunc 每次新建 goroutine积压大量待执行函数。每秒 tick 触发一次重置用 atomic.SwapUint64(qps, 0) 清零并拿到上一秒的值请求入口只做一次 atomic.AddUint64(qps, 1)无分支、无锁、无内存分配tick 频率必须严格为 time.Second不能用 time.Millisecond * 1000Go 1.20 有细微差异注意该方案统计的是“完成时间落在该秒内的请求数”不是“发起时间”但 HTTP server 处理耗时通常远小于 1s偏差可接受HTTP 中间件里怎么安全暴露 QPS 值QPS 是瞬时指标直接从变量读取即可不需要加锁或 channel 传递。但暴露方式决定是否线程安全和是否拖慢主流程。典型翻车点是把 qps 变量放进 http.ServeMux 的 handler 里每次调用 atomic.LoadUint64 —— 这本身没问题但若同时注册了 Prometheus 的 /metrics handler 并用 expvar 或自定义 collector容易因采集频率高而引发缓存行伪共享false sharing尤其在多核机器上 QPS 波动异常。立即学习“go语言免费学习笔记深入”暴露端点建议独立路由比如 /debug/qps响应体只写纯数字不带 JSON 包装避免在中间件里对每个请求都调用 atomic.LoadUint64 做日志或埋点高频日志会放大原子操作开销如果要用 Prometheus写一个 prometheus.Gauge在 tick 回调里用 Set(float64(atomic.LoadUint64(qps))) 更新不要在 Collect() 里现场读别用 expvar.NewInt(qps)它底层是 mutex map 查找比裸 atomic 慢一个数量级为什么不用 golang.org/x/time/rate 做 QPS 统计rate.Limiter 是为限流设计的不是为观测设计的。它内部维护的是 token bucket 状态没有提供“过去 N 秒平均请求数”的只读接口。 Tellers AI Tellers是一款自动视频编辑工具可以将文本、文章或故事转换为视频。