有人上升，有人下降：四个人与时间的答案

我用“两分钟法则”和“物理隔离”治好了我的拖延症

我用「两分钟清单」治好了拖延症：一个极简效率小方法


最近在做一个移动端商品列表页时，遇到了滚动明显卡顿的问题。测试机是三年前的中端安卓机，手指一滑就像在看幻灯片。这篇文章记录我是怎么一步步把帧率从惨不忍睹拉回基本流畅的。

## 现象与初步怀疑

最开始我以为是接口慢，因为首屏要渲染上百个卡片。但抓包发现数据 300ms 就回来了，DOM 也很快就画出来了。用 Chrome 远程调试一看，滚动时 Long Task 一大片，主线程被 JS 和样式计算吃满。

我第一反应是列表项太重：每个卡片有阴影、圆角、多张图，还有 hover 态的过渡动画。在桌面端无感，在弱机上是灾难。

## 先砍掉会触发重排重绘的东西

我把卡片的 `box-shadow` 换成了更轻量的渐变背景模拟层次；圆角保留但去掉了 `overflow:hidden` 里不必要的层叠上下文。最关键是关掉了滚动中的 `:hover` 和 `transition`——移动端本来就没有真实 hover，浏览器还会在滚动时反复计算状态。

另外给图片统一加 `loading="lazy"` 和固定宽高，避免滚动时频繁引起布局抖动。这一步做完，卡顿减轻但不算彻底解决。

## 用虚拟列表兜住 DOM 数量

商品可能上千条，全挂 DOM 里肯定不行。我上了简单的虚拟列表：只渲染可视区加缓冲区的几十个节点，滚动时回收复用。自己写了一个极简版，不依赖框架，核心就是监听 `scroll` 算 startIndex，用 `transform` 撑开容器高度。

注意别在 `scroll` 里直接操作 DOM，我用 `requestAnimationFrame` 节流，并把计算逻辑和渲染分离。改完之后，即便数据过万，滚动也稳了。

## 一点个人体会

移动端性能不能靠“感觉不卡”来判断，得看帧率和任务耗时。很多 PC 上优雅的写法，到手机上就是负担。先减负担，再控数量，比一上来就堆框架管用。这次排查让我更相信：前端优化往往不是高深算法，而是把不该做的事省掉。


分享移动端长列表滚动卡顿的排查思路与实用优化方案。最近在做一个移动端商品列表页时，遇到了滚动明显卡顿的问题。测试机是三年前的中端安卓机，手指一滑就像在看幻灯片。这篇文章记录我是怎么一步步把帧率从惨不忍睹拉回基本流畅的。 现象与初步怀疑 最开始我以为是接口慢，因为首屏要渲染上百个卡片。但抓包发现数据 …

一次移动端滚动卡顿的排查与优化实录

评论