scroll-view + offsettop 是跨端虚拟滚动唯一可行方案，因其绕过 document 依赖和 css transform 限制，适配小程序与 app 端。
scroll-view + offsetTop 是唯一能跨端跑通的方案
uni-app 没有原生虚拟列表，vue-virtual-scroller 这类依赖 document 和 CSS transform 的库，在小程序和 App 端直接报 document is not defined 或样式错乱，根本起不来。官方组件库、uView、z-paging 的“虚拟列表”底层也全是基于 scroll-view 手动算索引实现的——这不是妥协，是平台限制下的必然选择。
实操要点：
-
scroll-view必须设固定高度（如height: 600rpx），且scroll-y为true，否则scrollTop不触发 - 禁用
enable-back-to-top：它会劫持滚动事件，导致@scroll回调失灵 - 单行高度必须固定（比如
80rpx），或提前通过配置约定好；动态高度需用z-paging的cell-height-mode="dynamic"，但会牺牲部分性能 - 监听
@scroll，用Math.floor(event.detail.scrollTop / 80)得到可视起始索引，再取前后各 5 条作缓冲区
key 写成 index 就等于放弃稳定性
:key="index" 是长列表状态错乱的头号原因。Vue 在 diff 时会复用组件实例，一旦增删数据，input 输入框内容漂移、switch 开关状态错位、图片加载错图就全来了——这不是 bug，是 key 不稳定引发的必然结果。
正确做法：
- key 必须是数据源里稳定唯一的字段，比如
:key="item.id"或:key="item.sn" - 后端接口必须返回带唯一标识的字段，前端严禁用
Array.indexOf()或Math.random()生成伪 key - 如果后端没给 id，至少用
:key="item.timestamp + '-' + item.content.slice(0,10)"做弱唯一拼接，比index强
setData 和响应式开销比 DOM 更容易被忽略
真机卡顿、模拟器不卡，大概率不是渲染问题，而是 setData 超限或 Vue 响应式追踪崩了。小程序单次 setData 数据量上限通常 2MB，而 Vue 对每个 item 都要建立响应式代理——500 条含 10 个字段的对象，光代理开销就能拖垮内存。
规避手段：
- 别把整个列表塞进一个 data 字段（如
this.listData = allItems），改用this.visibleData = visibleItems+this.totalHeight = 80 * allItems.length拆开管理 - 滚动回调里别直接赋值
this.visibleData = ...，包一层this.$nextTick(() => { this.visibleData = ... })防 setData 冲突 - 列表项里避免
watch、深层computed、或嵌套 3 层以上的响应式对象
iOS 微信 scroll-view 卡顿，90% 是渲染层被拖垮
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 或样式正在重排
虚拟滚动真正的复杂点不在计算索引，而在跨平台一致性：小程序里 uni.createSelectorQuery() 是异步的，拿不到实时行高；App 端某些原生渲染层对 scroll-into-view 支持不全；而所有平台都对 setData 体积和响应式深度敏感。所以最稳的路径，是接受“固定行高 + 后端分页 + 稳定 key”这三件套，别在动态高度和前端过滤上硬刚。
