uni-app长列表卡顿主因是v-for未用唯一key、未分页懒加载及dom未复用；需固定行高、禁用index作key、后端分页、scroll-view手动实现虚拟列表并防抖校验。
uni-app里长列表卡顿，是因为没用v-for的key或没做懒加载
uni-app默认渲染整个v-for列表，哪怕有1000条数据，也会一次性创建1000个节点——小程序端直接白屏或严重卡顿，H5端滚动也掉帧。关键不是“能不能用虚拟列表”，而是“不加优化时，key写错、数据未分页、DOM没复用”这三件事最常触发性能崩塌。
实操建议：
-
key必须是稳定唯一值（比如item.id），禁用:key="index"，否则列表增删时会错误复用组件，导致状态错乱 - 后端接口务必支持分页（
page/pageSize），前端不做“全量拉取+前端过滤”这种事 - 避免在
v-for内调用方法（如@click="handle(item)"），改用data-*属性或计算属性缓存结果
uni-app没有内置虚拟列表，得靠scroll-view + offsetTop手动截取
官方组件库和uView等第三方UI库的“虚拟列表”组件，底层都是基于scroll-view监听scrolltoupper/scrolltolower，再配合offsetTop动态计算可视区域索引。它不像Vue 3的VirtualList那样自动管理ref，需要你明确控制“当前显示哪几项”。
实操建议：
- 给
scroll-view设固定高度（如height: 600rpx），并开启scroll-y，禁用enable-back-to-top（它会干扰滚动事件） - 监听
scroll事件时，用event.detail.scrollTop除以单行高度（需提前知道，比如80rpx），向下取整得起始索引：Math.floor(scrollTop / 80) - 只渲染前后各5条缓冲项（共11条），其余用
view占位，高度用height: calc(80rpx * 总数)撑开滚动条
uni-app跨端时scroll-view表现不一致，iOS卡顿常见于未关闭硬件加速
H5端滚动流畅但小程序卡，大概率是scroll-view在iOS微信里触发了重排。这不是代码逻辑问题，而是渲染层限制：iOS端scroll-view内部元素若含transform、opacity或过多flex嵌套，会强制走CPU渲染。
实操建议：
- 列表项样式尽量扁平，禁用
display: flex多层嵌套，用float或绝对定位替代复杂布局 - 给
scroll-view加style="will-change: scroll-position;"（仅H5有效），小程序端则要加class="scroll-view-fix"并配CSS：.scroll-view-fix { -webkit-overflow-scrolling: touch; } - 真机调试时，打开微信开发者工具的“渲染面板”，看是否频繁触发“Layout”——有就说明DOM结构或样式触发了重排
用uni.createSelectorQuery()测高会导致虚拟列表错位
有人想用uni.createSelectorQuery()动态获取每行真实高度来做精确截取，但这个API在小程序里是异步的，且多次调用会累积延迟。更麻烦的是，它返回的高度含padding/margin，而scroll-view滚动计算必须用纯内容高度，两者对不上，滚动到后面就会漏项或重复。
实操建议：
- 所有列表项必须用固定高度（比如统一
height: 80rpx），禁止用min-height或auto - 文字超长用
text-overflow: ellipsis截断，别依赖line-clamp（小程序不支持） - 如果真有变高需求（如富文本），按“最大可能高度”预设（比如120rpx），宁可留白也不能动态测高
虚拟列表不是加个组件就完事，核心在于“主动放弃渲染权”——你得自己算索引、控高度、截数据。最容易被忽略的是：iOS真机上scroll-view的scrollTop在快速滚动时会跳变，所以计算可视区间时一定要加防抖和边界校验，不然一划到底就空白。
