节流函数默认不执行最后一次触发，因其仅按固定节奏放行且无法感知事件结束；需通过暴露cancel方法、双模式节流或监听scrollend等原生结束事件来保障收尾执行。
节流函数默认不执行最后一次触发，是因为它只按固定节奏“匀速放行”，没有感知事件是否真正结束的能力。要避免丢失，关键不是改节流本身，而是给它加一层“收尾保障”。
暴露 cancel 方法手动兜底
在节流函数闭包中返回一个 cancel 函数，供外部在事件结束时主动调用：
- 定时器版：cancel 清除 pending timeout，并立即执行回调
- 时间戳版：cancel 设置标志位（如 shouldExecuteLast = true），并在下一次调用时检查并执行
- 实际使用中，可监听 scrollend（Chrome/Edge 116+）、transitionend 或组件卸载时机来触发 cancel
采用双模式节流结构
把时间戳判断和延迟定时器结合起来，兼顾响应速度与收尾可靠性：
- 每次触发先按时间戳规则判断是否立刻执行
- 同时启动一个较短延迟（例如 wait / 2）的定时器，作为“静默期探测器”
- 下次触发时，先清除旧定时器、重置时间戳，再重新设新定时器
- 这样即使高频触发突然停止，延迟定时器仍会在静默后兜底执行一次
配合原生结束事件使用
现代浏览器已提供部分事件的自然结束信号，比手动猜测更精准：
- scrollend：滚动完全停止后触发，适合滚动加载场景
- resize 搭配 ResizeObserver：比单纯节流更及时、更稳定
- 鼠标类事件（如 mouseup、mouseleave）可作为 touchend/mousemove 的补充触发点
不复杂但容易忽略：节流本身的设计目标就是“控频”，它本就不承诺执行每一次。需要兜底，就得跳出纯节流逻辑，用 cancel、双模式或原生事件来补位。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
