滚动监听需优化性能：用节流控制频率，IntersectionObserver替代手动计算，避免强制同步布局，按需启停监听器，并注意passive选项与内存泄漏。
滚动监听在 JavaScript 中很常用，但直接绑定 scroll 事件容易导致性能问题——它触发太频繁，可能每秒几十甚至上百次，造成卡顿或重绘压力。优化核心是控制执行频率、减少计算量、避免布局抖动。
节流（Throttle）滚动处理函数
限制函数在指定时间间隔内最多执行一次，适合需要稳定节奏的场景（比如导航高亮、滚动进度条）。
- 用
setTimeout+ 标志位实现轻量节流，例如 100ms 内只响应第一次滚动 - 也可用 Lodash 的
throttle(fn, 100)，但注意它默认使用 trailing（结尾执行），对实时性要求高的场景可设{leading: true, trailing: false} - 避免用防抖（debounce），它会延迟响应，不适合“边滚边更新”的需求
使用 IntersectionObserver 替代手动计算
监听元素是否进入/离开视口，比反复读取 getBoundingClientRect() 和 scrollTop 高效得多，且天然异步、不阻塞主线程。
- 适用于懒加载图片、无限滚动触底判断、吸顶导航激活等
- 创建时传入
{threshold: [0, 0.1, 1]}可监听不同可见比例 - 注意：需主动调用
unobserve()或disconnect()避免内存泄漏
避免在滚动中强制同步布局（Layout Thrashing）
读取 offsetTop、clientHeight 等属性后立刻写样式（如修改 top），会触发浏览器反复重排重绘。
立即学习“Java免费学习笔记（深入）”；
- 把读操作集中到一起，写操作集中到一起（“读-读-读 → 写-写-写”）
- 优先用 CSS 变换（
transform: translateY()）代替 top/left，它走合成层，不触发重排 - 必要时用
requestAnimationFrame()把更新对齐到下一帧，保证流畅
按需启用与销毁监听器
滚动监听不是“一绑永逸”，要配合生命周期管理。
- 页面不可见（
document.hidden === true）或组件卸载时，移除 scroll 事件或 disconnect IntersectionObserver - 移动端慎用 passive: false，默认 passive: true 可提升滚动流畅度；若需调用
preventDefault()（如自定义下拉刷新），必须显式声明{passive: false} - 复杂单页应用中，可封装 hook（如 React 的
useScrollPosition）自动处理启停
基本上就这些。关键不是堆技巧，而是根据实际需求选对工具：高频连续响应用节流 + rAF，进/出视口判断用 IntersectionObserver，再辅以合理的资源清理和样式避坑。不复杂但容易忽略。
