节流函数验证核心是检查高频触发下是否严格遵守时间间隔限制，需通过Jest模拟时间、验证执行次数/时机/参数/上下文/边界场景。
验证节流函数是否真正过滤了多余调用，关键不是看“它有没有执行”，而是看“它在高频触发下是否严格遵守时间间隔限制”。核心思路是：**模拟连续多次调用，检查实际执行次数、执行时机和参数传递的准确性**。
用 Jest 模拟时间 + 手动触发验证
借助 Jest 的 jest.useFakeTimers() 控制时间流逝，避免真实等待：
- 调用节流函数 10 次（比如在 5ms 内连续触发）
- 用
jest.advanceTimersByTime(200)快进到节流延迟结束 - 断言回调只被执行了 1 次（时间戳版），或 1～2 次（带 trailing 的版本）
- 检查
console.log或 mock 函数的调用参数是否与首次/末次触发一致
验证执行时机是否符合预期
节流不是“延后执行”，而是“按节奏执行”。要区分两种主流实现：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 时间戳版：首次调用立即执行，之后每 ≥ delay 才执行一次 → 验证第 1 次调用后，第 2 次执行是否发生在 ≥ delay 之后
- 定时器版（带 trailing）：可能在 delay 结束时补执行最后一次 → 验证末次调用是否被正确捕获并延迟执行
- 用
jest.getTimerCount()确认没有残留未清除的定时器（避免内存泄漏）
检查 this 和参数是否完整传递
节流函数常用于事件监听，容易丢失上下文和 event 对象：
立即学习“Java免费学习笔记（深入）”；
- 测试中传入带
this绑定的 mock 函数（如const fn = jest.fn().bind({ id: 'test' })） - 触发节流函数时传入自定义参数（如
throttled(1, 'a')） - 断言
fn.mock.calls[0][0]是 1、fn.mock.contexts[0]是{ id: 'test' } - 若用于 scroll 事件，还需模拟
event.target并确认其在节流后仍可访问
边界场景必须覆盖
真实项目中最容易出问题的是边缘情况：
- 快速连续触发 + 突然停止：验证是否漏掉最后一次（trailing 为 true 时应补执行）
- 节流中手动调用 cancel()：确认后续调用不再执行，且定时器被清除
- delay = 0 或负数：应降级为无节流，或抛错提示（根据设计选择）
- 高频率 + 超长 delay（如 5000ms）：验证不会因闭包引用导致内存持续增长
