节流在压测中用于精确约束每个vu单位时间请求频次，核心是独立计时计数、高精度低开销；常用滑动窗口硬限流或setinterval匀速发射，需结合引擎特性（如k6）实现，并注意时间源一致、不跨vu共享状态、排除网络耗时。
在全网并发压测脚本中，节流（throttle）不是用来“防抖”或优化前端体验的，而是要**精确约束每个虚拟用户（VU）单位时间内的请求频次**，避免瞬间洪峰击穿服务，同时模拟真实用户行为节奏。核心在于：每个 VU 独立计时、独立计数，不共享状态，且速率控制必须高精度、低开销。
用时间窗口 + 请求计数器实现硬性节流
这是最可靠、压测中最常用的方式。对每个虚拟用户维护一个滑动时间窗口（如 1 秒），记录该窗口内已发出的请求数，超限则等待或丢弃。
- 初始化时为每个 VU 创建私有变量：
lastWindowStart = Date.now()、requestCount = 0、maxRequestsPerWindow = 5（即 5 QPS） - 每次准备发请求前，检查当前时间是否已跨出窗口：
const now = Date.now();<br>if (now - lastWindowStart >= 1000) {<br> // 新窗口，重置计数器<br> lastWindowStart = now;<br> requestCount = 0;<br>} - 若
requestCount ，允许发送并 <code>requestCount++；否则调用await sleep(1000 / maxRequestsPerWindow)后重试（或直接跳过）
用 setInterval + 队列实现匀速发射（推荐用于长稳态压测）
适用于需要严格恒定速率（如稳定 10 QPS 持续 5 分钟）的场景。每个 VU 启动一个独立定时器，按固定间隔“弹出”一个请求任务。
- 预先构建操作队列（如 300 个请求配置），或用生成器函数动态产出
- 启动
setInterval，间隔 =1000 / targetQPS（例如 10 QPS → 每 100ms 触发一次） - 每次触发时，从队列取一个任务执行（HTTP 请求），并记录开始/结束时间用于后续统计
- 注意：Node.js 环境下需用
globalThis.setInterval或确保 timer 不被 GC；在非 Node 的压测引擎（如 k6）中，直接使用其内置sleep()和check()流程更稳妥
结合压测引擎特性做轻量节流（以 k6 为例）
k6 原生不提供 per-VU 节流 API，但可通过 rateLimit 模式或自定义逻辑高效实现：
- 用
__ENV.QPS_PER_VU || 3读取环境变量，让每个 VU 自行控制速率 - 在
default函数内封装节流逻辑，例如：const qps = __ENV.QPS_PER_VU ? parseInt(__ENV.QPS_PER_VU) : 2;<br>const interval = 1000 / qps;<br>if (lastReqTime && Date.now() - lastReqTime sleep((interval - (Date.now() - lastReqTime)) / 1000);<br>}<br>lastReqTime = Date.now();
- 避免用
setTimeout递归——易堆积、难调试；优先用同步阻塞sleep()（k6 支持）或await new Promise(r => setTimeout(r, ms))（Node 兼容）
关键细节与避坑点
节流失效往往不是逻辑错，而是忽略了运行时上下文：
-
时间源必须一致：不要混用
Date.now()和performance.now()；在高并发下，Date.now()调用本身有微小延迟，建议缓存时间戳或用更高精度 API（Node.js 中可用process.hrtime.bigint()） -
禁止跨 VU 共享节流状态：所有变量（
lastWindowStart、requestCount）必须定义在 VU 作用域内（如 k6 的init阶段或函数闭包中），不可挂到全局对象 - 网络耗时要排除在外：节流只管“发起”频率，不管响应时间。发送后立即计数，不要等 response 回来再计——否则实际 QPS 会远低于设定值
- 压测工具自身开销要预留：如果单个请求处理+序列化+加密耗时 > 10ms，设 100 QPS 可能导致 CPU 打满、定时不准，此时应降低目标 QPS 或升级执行机配置
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
