滚动卡顿主因是触发重排、强制同步布局或图层爆炸；须用passive: true、transform替代top/margin、节流布局读取、提升图层、长列表必用虚拟滚动。
滚动卡顿不是“浏览器慢”，而是你无意中触发了重排、强制同步布局或图层爆炸——优化关键不在加功能，而在砍掉那些默认就开火的渲染行为。
scroll事件监听器为什么一挂就掉帧
移动端每秒可能触发上百次 scroll，Chrome 默认把它标记为“可能调用 preventDefault()”，所以会等 JS 执行完才滚动，造成肉眼可见的延迟。
- 必须加
{ passive: true }：否则控制台报"Unable to preventDefault inside passive event listener"，且滚动明显滞后 - 别在回调里读
getBoundingClientRect()或写el.style.top：这会强制浏览器立刻计算布局（forced synchronous layout） - 读位置优先用
el.scrollTop，而不是window.scrollY：前者是同步但轻量，后者要跨文档查 - 真需要响应滚动位置变化？用
requestIdleCallback()或时间戳节流（比如只在停止后 100ms 执行）
用transform代替top/margin实现滚动位移
改 top 或 margin-top 会触发 Layout（重排），而 transform: translateY() 属于合成层操作，GPU 直接位移像素块，不碰主线程布局逻辑。
- 必须配合图层提升：加
transform: translateZ(0)或临时设will-change: transform（滚动开始前加，结束后 100ms 移除） - 位移值务必整数对齐：
element.style.transform = `translateY(${Math.round(y)}px)`，避免 subpixel 渲染模糊 - 禁用
transition做滚动：它不可控、无法暂停，且动画曲线不受限，极易卡顿 - 动画驱动必须用
requestAnimationFrame，不用setTimeout+ 样式写入
长列表滚动卡顿，虚拟滚动不是可选项而是必选项
当 DOM 节点超过 200 行，哪怕所有 CSS 优化都做了，主线程仍会被渲染树构建和样式计算拖垮。此时“隐藏”或“懒加载”已无意义，必须减少真实节点数量。
- 核心逻辑：只渲染视口内 + 上下缓冲 1~2 屏的节点，其余用精确高度的占位
<div> 替代 <li>监听 <code>scroll只更新scrollTop和当前起始索引，不增删 DOM、不改 innerHTML - 纯 HTML/CSS 方案可减负但不能动态加载：用
contain: strict声明容器，display: contents让包裹器不参与盒模型 - 图片必须
loading="lazy"+decoding="async"，滚动区域外的<img>别让它参与初始渲染 - 如果只是视觉滚动效果（如文字跑马灯），直接用
transform+requestAnimationFrame，别造滚动容器 - 避免
position: fixed或transform元素内部嵌套overflow: scroll：极易触发强制同步布局 - iOS Safari 对
overflow: scroll内的position: sticky支持极差，滚动中行为常失效 -
scrollBehavior: 'smooth'看似友好，实则让浏览器放弃原生滚动路径，改用 JS 插值模拟，每一帧都算，合成器线程直接阻塞
overflow: scroll 容器本身就在悄悄吃性能
只要元素有 overflow: scroll 或 auto，Blink/WebKit 就会为其创建独立合成层，触发图层切分、光栅化、合成器线程介入——这不是加个滑条那么简单。
真正难的不是写出让滚动“看起来动了”的代码，而是识别出哪些 CSS 属性、哪些事件监听、哪些 DOM 操作正在后台持续申请主线程资源——这些细节一旦漏掉，所有优化都会归零。
