局部滚动卡顿需同时满足硬件加速、事件不阻塞、布局不重算、DOM不爆炸四条件：-webkit-overflow-scrolling: touch 与 transform: translateZ(0) 必须共存；touchmove 需加 {passive: true}；避免 scroll 中读取 layout；长列表须虚拟滚动。
局部滚动卡顿不是代码写错了，是浏览器没被明确告知“这个区域要 GPU 渲染”，必须同时满足硬件加速、事件不阻塞、布局不重算、DOM 不爆炸这四个条件，缺一不可。
overflow: scroll 容器没触发硬件加速
只写 overflow-y: scroll，安卓 WebView 和部分 iOS 版本仍走 CPU 合成，帧率掉到 20–30fps。必须两行 CSS 同时存在：
-
-webkit-overflow-scrolling: touch（iOS 必开，安卓 WebView 也认） -
transform: translateZ(0)（强制创建独立合成层）
只加其中一条，尤其只加 translateZ(0)，在中低端安卓机上大概率还是卡。验证是否生效：Chrome DevTools → Rendering → 勾选 “Layer Borders”，滚动时看容器是否有绿色边框。
touchmove 监听器让原生滚动降级为 JS 驱动
只要给滚动容器绑了 touchmove，哪怕回调里只写了 console.log()，iOS 和很多安卓 WebView 就会禁用原生滚动优化——变成每帧都调 JS，一卡一卡。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 必须显式传
{ passive: true }：element.addEventListener('touchmove', handler, { passive: true }) - 绝对不要在回调里调
preventDefault()，否则passive: true失效 - 真需要拦截（如下拉刷新），改用
touchstart+touchmove组合，并只在必要时设passive: false
scroll 回调里读取 layout 触发强制同步布局
在 scroll 回调里调 getBoundingClientRect()、offsetHeight 或任何带“获取”字眼的 API，都会触发强制同步布局（forced synchronous layout），单次耗时轻松超 10ms，直接掉帧。
- 把 layout 读取移到
requestIdleCallback()或节流后的回调末尾 - 用
IntersectionObserver替代手动计算元素位置（适合懒加载、吸顶等场景） - 真要实时读，先缓存一次值，后续滚动中复用，直到
resize或orientationchange再更新 - 改用
transform: translateY()移动元素，它不触发 layout，只走合成层
长列表没做虚拟滚动，DOM 数量压垮渲染线程
超过 200 行的列表，哪怕所有 CSS 和事件都优化到位，低端安卓机仍会卡——不是逻辑慢，是内存和 DOM 树遍历成本太高。
- 只渲染视口内 + 上下各 1–2 屏的节点（通常 ≤ 20 条）
- 用一个
div占位撑起总高度：style="height: calc(var(--item-height) * var(--total-count))" - 滚动时仅更新
scrollTop和当前渲染索引，不增删 DOM - 别用
will-change: scroll-position试图“骗”浏览器优化，旧版 Web 不认
最容易被忽略的是：passive: true 和 translateZ(0) 必须成对出现，且滚动容器不能嵌套在 position: fixed 或已 transform 的父元素里——这种结构极易触发强制同步布局，连 layer borders 都可能不显示。
