uni-app表格卡顿主因是v-for全量渲染，应改用scroll-view+slice动态渲染可视区域数据，并设固定行高、节流setData、避免DOM测量；虚拟滚动需专用uni-app组件。
uni-app 里表格卡顿是因为 v-for 渲染了全部数据
uni-app 的 v-for 默认一次性渲染整个数组，哪怕你只显示前 20 行，它也会把 10000 条数据全塞进 DOM —— 页面直接卡死或白屏。这不是 uni-app 特有，但小程序平台（尤其是微信）对节点数和渲染深度极其敏感，比 H5 更容易触发性能瓶颈。
真正要做的不是“优化渲染”，而是“避免渲染不需要的行”：
- 用
slice()控制当前页可见数据，比如list.slice(start, end) - 配合
scroll-view滚动监听，动态更新start/end，而不是用scroll-view+v-for全量渲染 - 禁用
flex布局做表格行（尤其在 iOS 微信），改用display: table或固定宽高的view模拟表格结构，减少重排压力
怎么用 scroll-view 实现滚动加载（非触底分页）
“分段加载”不是等用户点“下一页”，而是在滚动过程中悄悄替换数据块。关键在于监听 scrolltoupper 和 scrolltolower 不够用 —— 它们只在顶部/底部触发一次。得靠 bindscroll + scrollTop 手动判断可视区域。
实操要点：
- 给
scroll-view设固定高度（height: 600px），并启用scroll-y - 每行设固定高度（比如
line-height: 80rpx），这样能用scrollTop / rowHeight算出当前偏移行号 - 维护一个
visibleRange = [start, end]，每次bindscroll触发时重新计算，并setData更新renderList - 别在
bindscroll里直接调this.setData—— 加个throttle（比如 100ms 间隔），否则 iOS 微信会丢 scroll 事件
uni.createSelectorQuery 不能用来测表格行高
有人想用 uni.createSelectorQuery 获取每行真实高度来适配不同内容，这在小程序里基本不可行：查询是异步的、批量节点查询容易超限、且首次渲染前查不到尺寸。更糟的是，它会强制触发 layout，让滚动更卡。
替代方案更务实：
- 所有表格行用固定高度（
height: 100rpx），内容用text-overflow: ellipsis截断 - 如果必须多行文本，限制最大行数（
display: -webkit-box+-webkit-line-clamp: 2），别依赖 JS 测高 - 真需要动态高度（如富文本），把这类行单独抽成“非虚拟滚动区块”，放在表格底部，不参与滚动复用
为什么 virtual-list 插件在 uni-app 里经常失效
很多 npm 上的 virtual-list 是为 Vue 3 + Web 设计的，直接 npm install 进 uni-app 后，会在小程序平台报 document is not defined 或 offsetHeight undefined —— 因为它们内部强依赖 DOM API，而 uni-app 小程序端没有 document。
能跑的只有专为 uni-app 写的虚拟滚动组件，比如：@dcloudio/uni-ui 里的 uni-load-more 不管用，但 uni-data-table（需搭配 loadMore + virtualRender 属性）或社区版 uni-virtual-list（注意看 GitHub issues 是否有小程序兼容修复）。
自己封装也简单：
- 只用
scroll-view+v-for渲染 3 倍可视区行数（比如看到 20 行，就渲染 60 行） - 用
transform: translateY()移动整块列表容器，而非移动每一行 —— 避免大量 style 计算 - 行元素加
key且唯一（比如:key="item.id + '_' + visibleStart"），防止复用错乱
最麻烦的其实是表头冻结和列宽同步 —— 这些没法靠虚拟滚动自动解决，得用 getBoundingClientRect 在 onReady 里手动对齐，而且 iOS 和安卓返回值还不一致。这事一旦开始做，就停不下来了。
