节流函数默认不保证最后一次触发执行，因其仅按固定间隔匀速执行而丢弃中间调用；时间戳版依赖时间差判断、定时器版依赖timeout状态，均无结束信号感知能力，需通过cancel机制、双模式设计或scrollend等原生结束事件补充兜底。

节流函数默认不保证最后一次触发一定执行——它只按固定间隔“匀速”执行，中间漏掉的调用会被丢弃。如果业务需要兼顾节奏控制和兜底执行（比如滚动到底部时必须触发加载），就得在基础节流逻辑上增加“尾部补偿”机制。

为什么默认节流会丢掉最后一次？

时间戳版节流靠比对 当前时间 - 上次执行时间 是否超过阈值，不满足就跳过；定时器版则依赖 timeout 未启动才设新定时器，若连续高频触发，定时器一直不空，最后那次就永远等不到机会。两者都缺乏对“结束信号”的感知。

加个“清空延迟队列”的 cancel 方法

让使用者能在事件结束时主动触发一次，比如监听 scroll 时在 scrollend 事件里调用 cancel：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 在闭包中暴露一个 cancel 函数，清除 pending 状态并立即执行回调
• 定时器版节流中，cancel 清除 timeout 并手动调用 func
• 时间戳版节流中，cancel 可设一个标志位（如 shouldExecuteLast），并在下一次调用时检查并执行

改用“双模式节流”：时间戳 + 定时器组合

兼顾即时响应与兜底执行，典型结构如下：

• 每次触发先检查时间戳，满足间隔就直接执行并更新时间
• 同时启动一个延迟定时器（比如 wait/2 后触发），用于捕获“长时间无新触发”后的收尾
• 下次触发时，先 clearTimeout，再重置时间戳和定时器
• 这样既保持主节奏，又确保静默期结束前至少执行一次

监听原生结束事件配合使用

现代浏览器已支持部分事件的结束钩子，可作为补充手段：

• scrollend（Chrome 116+、Edge 116+）：滚动自然停止后触发，此时调用节流函数的 cancel 或直接执行加载逻辑
• resizeobserver 配合防抖处理窗口变化，比单纯节流更精准
• 鼠标类事件可用 pointerup 或 mouseleave 触发兜底

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