节流函数单元测试需用jest的usefaketimers控制时间、验证调用频次与时机；核心是覆盖leading/trailing行为、this和参数透传、返回值处理，并通过advancetimersbytime等精确校验不同触发节奏下的执行逻辑。
节流函数的单元测试关键在于控制时间、验证调用频次与时机，而不是等真实时间过去。Jest 的 useFakeTimers 正是为此设计：它把 setTimeout 等 API 拦截成可快进、可触发的队列，让“300ms 内最多执行一次”这种逻辑变得确定、可断言。
节流函数的基本结构要明确
先确认被测函数是否符合标准节流语义（比如 leading/trailing 行为、this 和参数透传、返回值处理）。典型实现类似：
function throttle(fn, delay, options = {}) {
let timer = null;
const { leading = true, trailing = false } = options;
return function throttled(...args) {
const shouldInvoke = leading && !timer;
if (shouldInvoke) fn.apply(this, args);
if (!timer) {
timer = setTimeout(() => {
timer = null;
if (trailing) fn.apply(this, args);
}, delay);
}
};
}
测试前需确保该函数未被提前执行（如模块导入时就运行），且在 fake timers 启用后才调用。
启用 fake timers 并隔离测试环境
避免污染其他用例，推荐在 beforeEach 中启用，在 afterEach 中还原：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 调用
jest.useFakeTimers()替换全局定时器 - 用
jest.clearAllTimers()清空待执行队列（尤其当节流函数内部有 pending timeout） - 用
jest.useRealTimers()或在afterEach中还原，防止后续测试误用伪时间 - 不要在
beforeAll中启用却不afterAll还原，否则可能引发超时或跳过
分场景推进时间并校验调用行为
节流的核心是“单位时间内最多一次”，测试必须覆盖不同触发节奏下的响应：
-
快速连续调用（如 5 次/100ms）：调用函数后，立即检查
fn是否只执行 1 次（leading 成立时）；再推进delay时间，验证是否又执行 1 次（trailing 成立时） - 间隔大于 delay 的调用：两次调用间隔 > delay，应各自独立触发，共 2 次
-
边界时间点（如 delay - 1ms / delay + 1ms）：用
jest.advanceTimersByTime(delay - 1)验证不触发；再加 1ms 后触发 -
取消节流（clearTimeout 场景）：若节流函数返回了取消方法，需 mock
clearTimeout并验证其调用
校验 this、参数和返回值不能遗漏
节流函数常用于事件处理器，容易丢失上下文或参数：
- 用
jest.fn()创建带mockImplementation的回调，并记录this和args - 调用节流函数时绑定特定对象：
throttled.call(context, arg1, arg2) - 断言
fn.mock.calls中每次调用的this值、参数数组是否匹配预期 - 若节流函数本身有返回值（如防抖中常见），也要验证其行为（多数节流不返回，但需确认）
不复杂但容易忽略：节流不是简单地“延迟执行”，而是对高频输入做频率裁剪。fake timers 不是用来“加速等待”，而是把不可控的时间维度变成可控的步骤——推多少、断什么、清什么，每一步都得对应到业务逻辑上。
