app端nvue渲染必须用scroll-view而非view，因其映射为原生滚动组件；需设固定height、scroll-y为true，禁用flex嵌套，后端真分页，图片用webp并预加载字体，滚动监听须节流防抖。
App端nvue渲染必须用scroll-view，不能用view
uni-app在App端默认走webview渲染，一旦列表卡顿，第一反应不是逻辑问题，而是渲染模式错了。nvue（native vue）才是App端高性能的底层支撑，但必须显式启用——scroll-view组件在nvue下会映射为原生UIScrollView或RecyclerView，而普通view哪怕加了scrollable="true"，仍走webview层，滚动帧率直接掉到30fps以下。
实操要点：
- 页面json中必须声明
"style": {"navigationBarTitleText": "xxx"}并确保"usingComponents"未意外禁用nvue特性 -
scroll-view需设固定height（如height: 80vh），且scroll-y为true，否则nvue不接管滚动事件 - 禁止在
scroll-view内嵌套flex布局的容器——nvue对flex嵌套深度敏感，超过3层易触发重排回退到webview渲染 - 真机调试时打开HBuilderX的“运行日志”，看是否输出
nvue render start，没这行就说明没走nvue
分页请求必须带page和pageSize，后端不能返回全量数据
App端内存比小程序更宽松，但错误的分页逻辑一样致命：前端拉取10000条后自己slice(0,20)，等于把所有数据塞进JS堆，GC频繁、滚动延迟明显。nvue虽快，也扛不住10MB的this.listData。
正确做法是让后端真正分页：
- 接口必须支持
GET /api/list?page=1&pageSize=30，且响应体只含当前页30条+total总数 - 前端维护
currentPage和hasMore，触底时才发下一页请求，避免预加载造成冗余流量 - 不要用
uni.loadMore这种封装组件——它内部常做this.list = [...this.list, ...newData]，导致数组引用变更，nvue无法复用节点 - 用
Array.push(...newData)替代this.list = this.list.concat(newData)，保持数组引用稳定，利于nvue diff优化
滚动监听必须节流+防抖，bindscroll不能直改data
nvue下bindscroll事件频率极高（iOS可达60Hz），若每次回调都执行this.visibleList = this.list.slice(start, end)，会触发高频setData，造成主线程阻塞。这不是Vue响应式慢，是通信通道被挤爆。
关键控制点：
- 用
setTimeout或requestAnimationFrame做节流，间隔不低于16ms（即60fps下限），例如：if (this.scrollTimer) return; this.scrollTimer = setTimeout(() => { /* 更新逻辑 */ }, 16) - 计算
start/end索引时，必须基于固定行高（如itemHeight: 120），不能调用uni.createSelectorQuery——nvue不支持该API，调用即静默失败 - 更新
visibleList前，先用JSON.stringify比对新旧数组，避免无意义的setData - 滚动停止后100ms再清空
scrollTimer，防止快速滑动时缓冲区没跟上出现白屏
图片和字体资源必须压缩+预加载，lazy-load在nvue下无效
nvue不走WebView渲染管线，所以H5和小程序那套lazy-load、mode="widthFix"完全不起作用。图片解码由原生层完成，若未压缩，滑动时CPU解码线程满载，帧率骤降。
硬性要求：
- 所有列表图片必须用WebP格式，尺寸不超过屏幕宽度的1.5倍（如iPhone 15 Pro Max屏宽为430px，则图宽≤645px）
- 使用CDN参数强制压缩：
src="https://cdn.com/img.jpg?x-oss-process=image/resize,w_600,limit_0/format,webp" - 字体文件必须用
font-display: swap，并在App.vue的onLaunch中预加载关键图标字体：uni.loadFontFace({family: 'iconfont', source: 'url(/static/iconfont.woff2)'}) - 避免在列表项里用
background-image——nvue不支持CSS背景图懒加载，且无法控制解码时机
nvue长列表的性能天花板不在JS逻辑，而在资源交付链路是否闭环：从后端分页结构、网络传输压缩、到原生层解码控制，任一环脱节都会让scroll-view变成摆设。最常被忽略的是字体预加载和WebP强制转码——这两项不做，再好的虚拟滚动逻辑也会被图片解码拖垮。
