Zui近使用uniapp开发了一个小程序项目，小程序项目中有一个功Neng里有个100多条的列表，这个列表总是展示hen慢。

刚开始我以为是后台返回结果慢，后来发现不是。

其实是前端渲染把我整懵了渲染节点太多，卡得要死。

说实话，我也试过一次性把所有数据setData进去，结果页面直接白屏。

那种感觉，就像坐在公交上被挤得喘不过气来。

简单来说就是把长列表切成一块块的小块儿，只在视口附近渲染。

想象一下你在kan一本厚厚的书，手里只翻开几页，其余的dou藏在书脊里。

这就是分段渲染的核心思想。

先把原始数组按固定数量拆成二维数组。

const chunkedList = computed => { const chunks = for { chunks.push }) } return chunks })

每个块dou有唯一id，用来Zuokey和后续的可视性标记。

原生提供的IntersectionObserver跑在视图层，不会占用逻辑层的CPU时间。

我们只要监听这些块容器和视口的交叉状态就行了。

let observer = null const visibleMap = ref const heightMap = ref const startObserver = => { if observer.disconnect observer = uni.createIntersectionObserver observer.relativeToViewport .observe('.chunk-anchor', res => { const id = res.dataset.id const intersecting = res.intersectionRatio> 0 visibleMap.value = intersecting if { heightMap.value = res.boundingClientRect.height } }) } startObserver

当块进入缓冲区时把visibleMap对应位置设为true，内部item就会通过v-if挂载。

滑出缓冲区则立刻销毁，释放内存。

块被销毁后Ru果不留占位，滚动条会跳动甚至塌陷。

这里用了heightMap记录真实高度，再用CSS的min-height撑起空白。

这样即使内部节点被销毁，外层容器依旧保持相同高度，滚动体验丝般顺滑。

#1 setData不要一次性塞太多数据；Zui好分批次、分块geng新，否则会触发JS与视图层的大量通信，卡顿不可避免。

#2 key必须唯一；Ru果key重复，diff算法失效，会导致整棵树重新渲染，性Neng炸裂。

#3 缓冲区大小要合适；太小用户会kan到闪烁感，太大又失去优化意义。经验值大概是视口高度的1~1.5倍左右比较合适。

A：因为小程序页面本质上是运行在微信环境里的，并不是普通的HTML网页爬虫Ke以直接访问到的URL。百度爬虫抓不到对应的路由，也就自然无法收录啦。想让内容被搜索引擎kan到，需要配合Web端同构或提供独立的H5落地页进行SEO布局。

- 打开Performance标签，kan帧率波动；理想情况下保持在60fps左右。

- 用Timeline捕捉setData调用次数，Ru果出现“SetData频繁”警告，就说明还有优化空间了。

- 注意观察“Repaint”和“Layout”占比，高的话说明DOM变化太激进，需要进一步拆分或使用geng轻量样式。

- 在Android低配机上测试，多数卡顿来源于图片解码和大量节点绘制，所以尽量使用图片懒加载配合分段渲染。

- Ke以给每个块加上will-change:auto属性，让GPU提前Zuo好准备，不过别滥用，否则反而消耗显存。

- 对于需要SEO的小程序页面Ke以在服务端预渲染出HTML片段，然后在小程序端进行hydrate，只保留首屏数据，其余继续走分段渲染逻辑，这样既兼顾搜索引擎，又不牺牲用户体验。哈哈，这招听起来有点高级，其实就是把Web端同构思路搬到小程序里罢了。

LCP下降30%

Total Blocking Time下降50%

User Perceived Lag几乎消失

- 用真实设备跑一遍对比报告，你会惊讶地发现滚动Yi经流畅到手指根本感受不到任何阻力。害，这才叫爽啊！

"用了分段渲染，我家老奶奶dou说滑得跟喝水一样顺畅！"

"别再用一次性render千条数据，那是自找苦吃。"

"不对不对，我刚才说的是Chunk Size应该是10条，其实根据业务场景Ke以是5、20甚至30，dou行，只要保证每次渲染节点数量控制在几十个以内。" 哈哈，这么说大家心里有数啦。