滚动性能优化需节流监听、用intersectionobserver替代手动计算、启用硬件加速（如translatez(0)）、限制position: sticky数量、避免强制回流与高开销重绘。
滚动事件监听器会持续触发，不节流就卡
浏览器在滚动过程中每秒可能触发几十次 scroll 事件，尤其在高刷屏或触摸设备上更频繁。如果监听函数里直接操作 DOM、计算布局（如调用 getBoundingClientRect()）或触发重排，页面会明显掉帧。
实操建议：
- 必须用节流（throttle）或防抖（debounce），推荐节流——滚动中需响应中间状态（如吸顶导航）；防抖只适合“滚动结束才执行”的场景（如懒加载兜底）
- 优先用
requestIdleCallback()或IntersectionObserver替代主动监听：比如判断元素是否进入视口，IntersectionObserver不触发重排且原生异步，比手动scroll+getBoundingClientRect()高效得多 - 避免在
scroll回调中读写同一 DOM 元素的 offset/scroll/client 系列属性，这会强制同步触发回流
滚动容器设了 overflow: scroll 就一定开硬件加速？
不是。仅设 overflow: scroll 或 auto 不会自动启用 GPU 加速，浏览器仍可能用 CPU 渲染滚动内容。真正触发合成层（compositing layer）需要满足条件：
- 给滚动容器加
transform: translateZ(0)或will-change: scroll-position（注意：will-change别滥用，只对明确长期滚动的容器设置） - 确保容器有明确的尺寸（
width/height），否则部分浏览器无法创建独立图层 - 避免容器内存在
filter、opacity 、<code>mask等强制新建图层但又不稳定的 CSS 属性，它们可能引发频繁图层重组
验证是否生效：Chrome DevTools → Rendering → 勾选 “Layer Borders”，滚动时看容器是否有绿色边框（表示独立合成层）。
position: sticky 在长列表中滚动卡顿的根源
position: sticky 看似轻量，但在成百上千项的列表中，每个 sticky 元素都会在每次滚动帧中参与粘性边界计算。浏览器需反复检查其父容器滚动偏移与自身 top/bottom 的关系，开销随 sticky 元素数量线性增长。
实操建议：
- 限制 sticky 元素数量，比如只让一级标题 sticky，而非每行都设
sticky - 用虚拟滚动（virtual scrolling）替代真实渲染全部 DOM：只渲染可视区域 ± 缓冲区内的项，配合
IntersectionObserver动态更新 sticky 状态 - 若必须全量渲染，可将 sticky 行提取为固定定位（
position: fixed），由 JS 手动控制其top值——虽然逻辑稍重，但避开浏览器内置 sticky 计算，反而更可控
滚动性能瓶颈常藏在看不见的“重绘”里
很多页面滚动流畅，但手指一松就卡一下，问题往往不在滚动本身，而在滚动停止后触发的重绘（paint）：比如懒加载图片解码、字体加载完成重排、CSS 动画补间计算等。
- 用 Chrome DevTools → Performance 录制滚动+释放全过程，重点关注 “Paint” 和 “Raster” 阶段的耗时峰值
- 图片懒加载优先用
loading="lazy"（原生支持），而非 JS 实现；对关键首屏图禁用 lazy，避免滚动后集中解码 - 避免在滚动临近结束时批量插入带阴影/渐变/复杂 border-radius 的元素——这些属性会显著增加光栅化（raster）压力
真正影响体验的，往往是那一帧多出的 8ms 绘制时间。它不来自滚动监听，而来自你没盯着看的绘制流水线末端。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
