滚动卡顿本质是浏览器渲染管线被高频低效操作打断；关键风险点在于overflow: scroll/auto容器、强制同步布局、未节流scroll事件、缺乏硬件加速及虚拟滚动缺失。
滚动卡顿不是“样式没调好”或“设备太差”，而是浏览器渲染管线被高频、低效操作反复打断。关键判断：只要页面里有 overflow: scroll 或 overflow: auto 容器，且内容超过一屏，性能风险就已存在——无论你有没有写 JS。
scroll 事件监听器为什么一加就卡
桌面 Chrome 中 scroll 事件每秒可触发 60+ 次，移动端更密集。每次回调若读取 scrollTop、调用 getBoundingClientRect() 或修改 style.transform，都会强制浏览器同步计算布局（forced synchronous layout），直接拖垮帧率。
- 必须加
{ passive: true }：否则 Chrome 会等 JS 执行完才滚动，产生明显延迟；控制台报错 “Unable to preventDefault inside passive event listener” 就是没加它 - 节流不能只靠
setTimeout：推荐用时间戳 +requestIdleCallback，比如只在滚动停止后 100ms 再执行视差逻辑 - 读取位置优先用
element.scrollTop：比window.scrollY少一次跨文档查询，开销更低
transform 替代真实滚动的适用边界
当滚动只是视觉动效（如轮播、跑马灯、固定高度内容位移），transform: translateY() + will-change: transform 能绕过合成层创建和重排，GPU 加速更稳；但一旦需要用户主动拖拽、惯性滑动、或依赖原生滚动语义（如锚点跳转、scrollIntoView），就必须保留真实滚动容器。
- 禁止在
position: fixed或已transform的父元素内嵌套overflow: scroll：极易触发强制同步布局 -
will-change: transform要按需开关：滚动开始前加，结束 100ms 后移除；长期挂着会导致内存浪费和纹理泄漏 - iOS Safari 对
position: sticky在overflow: scroll容器内支持不稳定，滚动中可能失效
长列表必须用虚拟滚动，不是“可以考虑”
200 行以上表格或聊天记录，哪怕所有 CSS 优化都做了，DOM 节点过多仍会拖慢滚动。虚拟滚动不是 JS 库专利，核心是只渲染可视区域 + 缓冲区，其余用精确高度占位。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 监听
scroll只更新scrollTop和当前渲染起始索引，不新增/删除 DOM - 用
contain: strict声明滚动容器：告诉浏览器其内容变化不影响外部布局，跳过部分样式重算 -
display: contents可让包裹容器不参与盒模型计算，减少布局开销（但兼容性需确认）
自定义滚动条本身就会触发合成层
哪怕只是改个颜色，::-webkit-scrollbar 也会让浏览器把该容器识别为可滚动区域，触发图层切分。这不是样式问题，是渲染机制决定的。
- 慎用
scrollBehavior: 'smooth'：它会让浏览器放弃原生滚动路径，改用 JS 动画模拟，每一帧都要重算，合成器线程易阻塞 - 对滚动区域外的
<img>必须设loading="lazy"+decoding="async"，否则图片加载会抢占主线程 - Chrome DevTools 的 Layers 面板要常看：确认是否出现不必要的合成层合并或过度绘制
真正容易被忽略的，是 overflow 属性本身——它不像 class 那样显眼，却在 DOM 渲染初期就锁定了合成策略。改一个 overflow: hidden 为 auto，可能就多出一个图层、多一次光栅化、多一次合成器线程调度。优化不是堆技巧，而是从第一个 div 开始，就清楚它会不会滚动、要不要滚动、值不值得滚动。
