滚动容器的 overflow 属性会触发合成层创建与重排重绘，导致性能问题；应优先用 transform 替代真实滚动，节流滚动事件，采用虚拟滚动、contain: strict 和 CSS 滚动时间线优化性能。
滚动容器的 overflow 属性直接影响渲染管线
浏览器对 overflow: scroll 或 overflow: auto 的处理不是“加个滑条”那么简单。一旦元素被识别为可滚动容器，Blink/WebKit 会为其创建独立的合成层（compositing layer），触发图层切分、光栅化和合成器线程介入。这在低端设备上容易引发掉帧，尤其当容器内有大量 DOM 节点或频繁重排的子元素时。
- 如果只是需要视觉滚动效果但内容固定，优先用
transform: translateY()+will-change: transform替代真实滚动，避免创建滚动容器 - 避免在
position: fixed或transform元素内部嵌套overflow: scroll，这类组合极易触发强制同步布局（forced synchronous layout） - iOS Safari 对
overflow: scroll容器内的position: sticky支持不稳定，滚动中 sticky 行为可能失效
滚动事件监听器是性能杀手，尤其没节流时
scroll 事件在桌面 Chrome 中每秒可触发 60+ 次，移动端更频繁。直接在监听函数里读取 scrollTop、调用 getBoundingClientRect() 或修改样式，会强制浏览器反复计算布局（layout）和绘制（paint）。
- 必须用
requestIdleCallback或setTimeout+ 时间戳做节流，例如：只在滚动停止后 100ms 再执行视差逻辑 - 读取滚动位置优先用
element.scrollTop（同步但轻量），而非window.scrollY（需跨文档查询） - 修改样式尽量走 CSS 变量 +
will-change，而不是直接改style.left或style.transform
虚拟滚动（virtual scrolling）不是 JS 库专属，HTML+CSS 也能轻量实现
长列表卡顿的根源是 DOM 节点过多。框架如 React/Vue 的虚拟滚动组件本质是动态替换 innerHTML 并调整容器 scrollTop 和子项 transform。纯 HTML/CSS 方案虽不能动态加载数据，但可通过以下方式减负：
- 用
display: contents让包裹容器不参与盒模型计算，减少布局开销 - 对滚动区域外的
<img alt="HTML滚动和性能优化有关系吗_性能优化中HTML滚动用法【深度解析】" >设置loading="lazy"，并配合decoding="async" - 用
contain: strict声明滚动容器，告诉浏览器其内容变化不会影响外部布局，可跳过部分样式重算
滚动行为 smooth 导致合成器线程阻塞
scrollBehavior: 'smooth' 看似无害，但它会让浏览器放弃原生滚动优化路径，转而用 JS 动画模拟滚动——这意味着每一帧都要计算插值、更新 scrollTop、触发重绘。在低端 Android 设备上，它甚至会阻塞主线程达数百毫秒。
立即学习“前端免费学习笔记（深入）”；
- 生产环境慎用全局
html { scroll-behavior: smooth; }，建议仅对特定锚点链接加scrollIntoView({ behavior: 'smooth' }) - 如果必须平滑滚动，用
CSS @scroll-timeline+animation替代 JS 控制（Chrome 115+），它运行在合成器线程，不占主线程 - 检测是否支持 smooth：用
'scrollBehavior' in document.documentElement.style，不支持时 fallback 到 instant
滚动性能问题往往藏在「看起来很普通」的 HTML 结构里——比如一个没加 contain 的 div 套着 overflow-y: auto，再里面是 200 行 flex 子项。这种组合在 DevTools 的 Rendering 面板里看不出异常，但一滚动就掉帧。真正要盯住的，是合成层数量、图层光栅化耗时，以及每次滚动是否触发了 Layout。
