节流函数在滚动监控中需“精准触发”，关键在于兼顾leading与trailing、启用passive: true、用requestanimationframe对齐渲染帧，并剥离重操作。
节流函数在滚动监控中要“精准触发”，关键不是压低频率，而是让每次执行都落在真正需要响应的时机上——既要刚滚动就感知（leading），又不能漏掉停在临界点的最后判断（trailing），还要避开浏览器底层阻塞和渲染陷阱。
必须开启 passive: true
这是比节流更前置、更硬性的性能开关。现代浏览器对未声明 passive: true 的 scroll 监听器，默认启用同步阻塞机制。哪怕回调里只有一行 console.log，也会打断原生滚动流畅性，造成卡顿或输入延迟。
- 正确写法：
element.addEventListener('scroll', handler, { passive: true }) - 例外情况：只有需调用
preventDefault()（如下拉刷新）时才设passive: false，且务必配合节流控制调用密度 - 注意：IE 不支持该选项，如需兼容，可用特性检测 + fallback
选对节流模式：leading + trailing 组合最稳妥
滚动场景常有两类关键响应点：刚动就要反馈（比如吸顶导航显隐），停稳后还要兜底一次（比如触达底部加载更多）。单靠时间戳版节流容易漏掉最后一次；纯定时器版又可能延迟首帧。
- 推荐配置：
{ leading: true, trailing: true } - leading = true → 第一次滚动立即执行，不等待间隔，保障初始响应
- trailing = true → 最后一次触发后，若未达间隔，仍会在计时器到期时补发一次，避免临界位置误判
- 避免把 event 对象直接传入闭包：滚动事件对象是复用的，节流后拿到的可能是过期引用；应只取所需字段（如
target.scrollTop）并缓存
用 requestAnimationFrame 对齐渲染帧
固定毫秒数节流（如 100ms）无法适配不同刷新率屏幕（60Hz/90Hz/120Hz），反而导致丢帧。真正的“精准”是让逻辑执行与屏幕刷新节奏一致。
- 滚动监听回调里只做两件事：更新
scrollTop缓存 + 判断是否已注册 RAF - 用布尔标志（如
isQueued）防止重复注册requestAnimationFrame - 所有真实逻辑（位置计算、class 切换、DOM 更新）统一放进 RAF 回调中执行
- 这样既守住 60FPS，又确保每次处理都落在帧边界内，视觉更顺滑
剥离重操作，节流只管节奏，不管轻重
节流解决的是“太密”，不是“太重”。即使加了节流，以下操作仍会直接拖垮帧率：
- 避免在回调中读取
offsetHeight、getBoundingClientRect()等触发强制同步布局的属性 - 长列表滚动改用虚拟滚动，只维护可视区少量节点，而非全量 DOM 更新
- 复杂计算（如千条数据实时过滤）应移交 Web Worker，或改用防抖后延后执行
- 动画相关样式优先用
transform+will-change: transform，交由 GPU 合成
