uni-app长列表卡顿本质是Vue渲染节点过多叠加小程序平台限制，需用虚拟滚动、图片懒加载、数据拆分等方案优化。
uni-app 长列表卡顿，本质是 Vue 渲染节点过多 + 小程序平台限制
uni-app 的长列表（比如几百条商品、聊天记录）在微信小程序或 app 端卡顿，不是代码写错了，而是 v-for 直接渲染全部项时，触发了两个硬约束：小程序单次 setdata 数据量上限（通常 2mb）、以及 vue 响应式系统对大量对象的依赖追踪开销。真机上尤其明显，模拟器几乎不卡——这说明问题不在逻辑，而在平台执行层。
实操建议：
- 别用
v-for渲染全量数据，哪怕你只显示前 20 条，Vue 仍会为全部 500 条创建 VNode 和响应式代理 - 优先用「虚拟滚动」思路：只渲染可视区域 ± 缓冲区内的 item，其余用
height: 100vh占位，靠scroll-top动态计算起始索引 - 避免在列表项里放
watch、computed或嵌套深层响应式对象（比如每个 item 是个带 10 个字段的 Object）
uni-app 虚拟滚动不能直接用 vue-virtual-scroller
vue-virtual-scroller 依赖 document 和 CSS transform，而 uni-app 编译到小程序时没有 DOM，App 端也走的是原生渲染层，这个库根本跑不起来。强行引入只会报 document is not defined 或样式完全错乱。
实操建议：
- 用
uni.createSelectorQuery()+scroll-view的scroll-top事件手写简易虚拟滚动逻辑 - 关键参数要设缓冲区（buffer），比如可视区高 600px，每项高 120px，则一次最多渲染 5 + 2（上下各 1 条缓冲）= 7 条，避免快速滚动时白屏
- 列表容器必须设固定高度（
style="height: 600px"），且scroll-view的scroll-y必须为 true，否则scroll-top不触发 - 别在
scroll回调里直接this.list = ...，用this.$nextTick包一层，防止频繁 setData 冲突
uni-app 列表卡顿还常因图片未懒加载或尺寸失控
小程序里 image 组件没做自动懒加载，滑动时大量图片同时解码，CPU 直接拉满。更隐蔽的是：如果没设 mode="widthFix" 或固定宽高，uni-app 会等图片加载完才计算布局，导致 layout thrashing。
实操建议：
- 所有列表中的
image必须加lazy-load属性（H5 无效，但小程序和 App 有效） - 显式设置
width和height，或用mode="aspectFill"+ 容器overflow: hidden控制裁剪 - 避免用
background-image渲染列表图——小程序不支持 background 图片懒加载，且无法控制解码时机 - 大图（>100KB）提前压缩，或用 webp 格式；uni-app 的
uni.downloadFile不会自动转 webp，得后端配合
uni-app 页面级 setData 性能陷阱
很多人把整个列表数组塞进一个 data 字段，比如 this.listData = [...]，每次更新都触发全量 diff。小程序 setData 是异步且有队列机制的，高频 scroll 下容易堆积，造成延迟感。
实操建议：
- 拆分数据源：把「元数据」（id、title）和「状态数据」（isLiked、count）分开管理，只更新变化的部分
- 用
this.$set或Vue.set更新单个 item 字段，而不是重赋整个数组 - 慎用
Object.assign({}, item)创建新对象——这会让 Vue 重新追踪整个对象，改用{...item, isLiked: true}更轻量 - App 端可启用
vue.config.js中的optimization: { subModule: true }（仅 HBuilderX 3.9+），减少模块间冗余响应式绑定
最麻烦的点其实是：同一个写法，在微信小程序里卡，在 H5 里飞快，开发者第一反应总以为是自己逻辑慢。其实只是平台渲染路径不同，得按平台特性来切方案，而不是找“通用最优解”。
