uni-app长列表卡顿源于setData限制、响应式开销和DOM爆炸三重问题；最稳妥方案是scroll-view+offsetTop手动实现虚拟滚动，需固定高度、禁用back-to-top、计算可视索引、合理设key及分页。
uni-app长列表卡顿，不是“要不要用虚拟列表”的问题，而是不加约束地用 v-for 渲染全量数据时，直接触发小程序 setData 限制、Vue 响应式追踪开销、DOM 节点爆炸这三重硬伤——真机上白屏或掉帧，模拟器几乎不卡，就说明是平台执行层崩了。
为什么 scroll-view + offsetTop 是最稳妥的虚拟滚动方案
uni-app 没有原生虚拟列表组件，vue-virtual-scroller 这类依赖 document 和 CSS transform 的库，在小程序和 App 端会报 document is not defined 或样式错乱，根本跑不起来。官方和 uView 的“虚拟列表”组件，底层也全是基于 scroll-view 手动计算可视索引实现的。
实操要点：
-
scroll-view必须设固定高度（如height: 600rpx），并开启scroll-y，禁用enable-back-to-top（它会劫持滚动事件） - 监听
@scroll事件，用event.detail.scrollTop除以预设行高（比如80rpx），取整得起始索引：Math.floor(scrollTop / 80) - 只渲染可视区域 ± 缓冲项（例如前后各 5 条），其余用空
<view></view>占位，总高度靠height: calc(80rpx * 总数)撑开滚动条 - 滚动回调里别直接赋值
this.visibleData = ...，包一层this.$nextTick防止 setData 冲突
key 写成 index 就等于埋雷
用 :key="index" 是长列表状态错乱的头号原因。列表增删时，Vue 会错误复用组件实例，导致 input 输入框内容漂移、开关状态错位、图片加载错图——这不是 bug，是 key 不稳定引发的必然结果。
正确做法：
- key 必须是数据源里稳定唯一的字段，比如
:key="item.id"或:key="item.sn" - 后端接口必须支持分页（
page/pageSize），前端严禁“全量拉取 + 前端过滤” - 避免在
v-for内调用方法（如@click="handle(item)"），改用data-id属性或计算属性缓存结果
iOS 微信里 scroll-view 卡顿，大概率是渲染层被拖垮了
H5 端滚动流畅但小程序卡，尤其 iOS 微信，不是代码逻辑问题，而是 scroll-view 内部元素触发了 CPU 渲染：含 transform、opacity、多层 flex 嵌套，都会让 iOS 强制放弃硬件加速。
可立即生效的缓解措施：
- 列表项样式尽量扁平，禁用超过两层的
flex嵌套，用position: absolute或float替代复杂布局 - 给
scroll-view加 class：class="scroll-view-fix"，配 CSS：.scroll-view-fix { -webkit-overflow-scrolling: touch; } - H5 端可加
style="will-change: scroll-position;"，小程序无效但无害 - 真机调试时打开微信开发者工具“渲染面板”，看是否频繁触发 “Layout” —— 有就说明 DOM 或样式正在强制重排
真正难的不是写出来，而是把行高钉死、把 key 钉稳、把分页接口对齐、把 scroll-view 的渲染陷阱一个个绕过去。这些地方一旦松动，虚拟滚动就退化成“看起来像优化”的幻觉。
