节流必须用闭包以私有持久维护状态；时间戳版靠lasttime实现立即执行与保频，适合scroll/resize；定时器版靠timer重置实现最后一次执行，适合搜索/加载；增强版融合leading+trailing需多状态协同；raf版适用于dom渲染优化，对齐刷新节奏更流畅。
节流必须用闭包，核心是为了在多次事件触发中私有、持久地维护执行状态，同时避免不同实例互相干扰。没有闭包，状态只能挂全局或对象属性上，一碰就乱。
时间戳版：靠 lastTime 控制“保频”节奏
适合 scroll、resize 这类需要稳定输出频率的场景。首次触发立刻执行，之后只在间隔达标时放行。
- 闭包内声明 let lastTime = 0，每次调用读取并更新它，不依赖外部传参
- 用 Date.now() - lastTime >= delay 判断是否满足间隔，逻辑直白无延迟偏差
- 不启用定时器，节省资源，响应更及时；但不支持“最后一次补发”这类柔性需求
定时器版：靠 timer 管理“收尾”时机
适合输入搜索、滚动加载更多等“松手后才响应”的交互。每次触发都重设 setTimeout，最终只执行最后一次。
- 闭包内声明 let timer = null，每次先 clearTimeout(timer) 再赋新值
- 回调执行后必须手动置 timer = null，否则残留 ID 可能导致后续判断失效
- 天然支持 trailing 行为，但首次触发有延迟，不适合需要立即反馈的场景
增强版：leading + trailing 需统一状态闭环
业务常要求“第一次马上动、最后一次也得补”，这时单靠 lastTime 或 timer 都不够，必须把多个状态封进同一个闭包里协同管理。
- 闭包内同时持有 lastTime、timer、pending（或 hasPending） 等标志位
- leading 为 true 时，首次调用直接执行并更新 lastTime；trailing 为 true 时，需在定时器回调里二次检查是否该补发
- 所有判断逻辑共享同一作用域变量，比如 trailing 回调里要读 lastTime 做时间过滤，不能跨闭包通信
视觉场景可考虑 requestAnimationFrame 替代 delay
如果目标是 DOM 渲染优化（如吸顶、视差、懒加载），硬编码 16ms 不如用 RAF 对齐浏览器刷新节奏。
- 闭包内维护 isQueued = false，确保同一帧只注册一次 RAF
- 事件回调只做数据采集（如缓存 scrollTop），RAF 回调里再批量处理 DOM 更新
- 无需手动管理 delay 和清除逻辑，天然防抖+节流混合效果，且更省电、更流畅
