防抖函数临界测试需用 Jest 假定时钟精确控制时间：调用 jest.useFakeTimers() 后，用 jest.advanceTimersByTime() 推进至 delay−1ms（应不执行）、exactly delay ms（应执行1次）、或重置后验证清除原定时器；同时检查参数传递、this 绑定、cancel() 可靠性及多实例隔离。
测试防抖函数在临界状态的执行，核心是**精确控制时间点与调用节奏**，验证它是否在「最后一次触发后等待指定延迟才执行」，且中间频繁调用不会提前或重复执行。关键不在“高频”本身，而在“最后一次触发与延迟结束之间的时间差是否刚好卡在边界上”。
模拟精确时间点：用 jest.useFakeTimers() 控制时钟
真实 setTimeout 无法精准断言临界行为。必须用 Jest 的假定时钟，手动推进时间：
- 调用 jest.useFakeTimers() 启用虚拟计时器
- 每次触发防抖函数后，用 jest.advanceTimersByTime(ms) 推进指定毫秒（比如刚好推进到 delay 结束前 1ms、恰好等于 delay、或超过 delay）
- 用 expect(fn).toHaveBeenCalledTimes(n) 断言执行次数，确认未提前触发
例如：delay = 100ms，连续触发 5 次（t=0,20,40,60,80），应在 t=180ms 后首次执行 —— 此时 advanceTimersByTime(179) 应为 0 次，advanceTimersByTime(180) 应为 1 次。
覆盖典型临界场景：延迟前/后/重置瞬间
真正容易出错的是这些边界：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 最后一次调用后，立即推进到 delay - 1ms：应无执行（计时器仍在运行）
- 推进 exactly delay ms：应执行且仅执行一次
- 在 delay 到来前再次触发（即“重置”）：原定时器应被清除，新倒计时开始；需验证旧回调未执行
- 连续快速触发 + 突然停止 + 精确等待：模拟用户输入停顿的临界停顿（如 99ms 停顿后等 100ms）
避免常见陷阱：this、参数、返回值与清理
临界测试还要检查防抖函数自身的健壮性：
- 多次调用是否始终把最后一次调用的参数传给回调（而非第一次或随机某次）
- 是否正确绑定 this 上下文（尤其用 call/apply 触发时）
- 防抖函数返回的取消函数（如
cancel()）是否真能阻止后续执行 —— 在 delay 剩余 10ms 时调用 cancel，再 advanceTimersByTime(100) 应仍为 0 次 - 连续两次调用防抖函数（不同实例），确保彼此计时器不干扰
补充：用 performance.now() 辅助验证（非单元测试主干）
在集成或性能测试中，可结合 performance.now() 打点记录真实耗时，确认实际延迟是否稳定（比如 100ms 防抖在 Chrome 中实测是否落在 95–105ms 区间）。但这属于观测手段，不能替代基于 fake timers 的确定性断言。
