节流在窗口滚动监听中用于控制回调频率以保障帧率稳定，推荐用requestAnimationFrame实现帧级节流，辅以passive监听、值缓存和class切换等优化措施。
节流在窗口滚动监听中主要用来控制回调执行频率，防止因滚动事件过于频繁（每秒可达60–120次）导致主线程过载、掉帧或卡顿。要真正保证帧率稳定，关键不是单纯“限制次数”，而是让逻辑对齐浏览器刷新节奏（通常60fps即每16.6ms一帧），避免强制同步布局和重复计算。
用 requestAnimationFrame 实现帧级节流
这是最推荐的方式，它天然与屏幕重绘同步，不会引发回流抖动，且无需手动管理时间戳：
- 每次 scroll 触发时，仅注册一次 rAF 回调；若已有待执行任务，则跳过新注册
- rAF 回调内执行全部逻辑：读取 scrollY、判断元素位置、更新样式等
- 所有 DOM 读写操作集中处理，避免“读-写-读-写”式布局抖动
手写时间戳节流（适合轻量场景）
若需精确控制最小间隔（如固定 16ms 或 100ms），可用时间戳实现稳定节流：
- 记录上一次执行时间，当前时间减去该值 ≥ 设定延迟才执行
- 设 delay = 16 可逼近 60fps；设 100–160ms 更适合 ScrollSpy 类视觉反馈
- 注意 this 和参数需通过 apply 正确传递，避免上下文丢失
必须配合的性能防护措施
光有节流不够，还需从源头减少开销：
立即学习“Java免费学习笔记（深入）”；
- 监听时加 { passive: true }，明确不调用 preventDefault()，让滚动进入合成线程
- 提前缓存需反复读取的值（如容器 clientHeight、目标元素 offsetTop），不在 scroll 回调里实时调用 getBoundingClientRect()
- 避免在节流回调中直接修改 style，优先用 class 切换或 transform/opacity 等触发硬件加速的属性
不要混淆节流与防抖的适用场景
滚动监听需要持续响应位置变化，比如吸顶导航、进度条、视差效果——这类必须用节流；而搜索框输入、窗口 resize 后重新布局才适合防抖。误用防抖会导致视觉滞后，用户已滚过目标区域，高亮却迟迟不更新。
