节流函数验证核心是检查高频触发下是否严格遵守时间间隔限制，需通过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 对象：

• 测试中传入带 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）：验证不会因闭包引用导致内存持续增长

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南