必须用list组件替代scroll-view，因nvue中scroll-view基于WebView无法触发原生复用机制，导致内存暴涨、卡顿甚至闪退；list调用原生UITableView/RecyclerView，支持视图复用与懒加载，但需固定行高、禁嵌套滚动组件、用image标签等约束。
App端长列表卡顿，在nvue页面里不能靠优化scroll-view解决，必须换用list组件——这是uni-app对原生渲染层的硬性要求，不是可选项。
为什么nvue里scroll-view在App上必然卡顿
nvue是基于原生渲染的，但scroll-view仍是Webview层封装的滚动容器，它无法触发原生列表的回收复用机制。iOS和Android平台都会把大量DOM节点塞进一个WebView上下文，导致内存暴涨、主线程阻塞。真机测过就知道：scroll-view渲染500条带图片的item，App端首屏渲染超2秒，滚动掉帧严重，且无法通过CSS或JS优化绕过。
- Android上常见
OutOfMemoryError或白屏闪退 - iOS上会触发WKWebView强制重排，
Layout耗时飙升（开发者工具“渲染面板”可验证） - 即使加了
will-change: scroll-position或-webkit-overflow-scrolling: touch也无效——这些只对Webview生效，nvue不走这套路径
必须用list组件替代scroll-view
list是uni-app为nvue专门设计的原生列表容器，底层调用的是iOS UITableView 和 Android RecyclerView，天然支持视图复用、懒加载、局部更新。它不接受任意HTML结构，只认cell和header子节点，但换来的是1000+条数据滚动如丝般顺滑。
- 固定行高是前提：必须设置
height属性（如height="120"），否则无法计算可视区域 - 禁止嵌套
scroll-view或swiper：它们与list的原生滚动冲突，会导致手势失效 - 图片必须用
image组件（非img标签），并启用lazy-load和mode="aspectFill" - 数据更新要用
this.$refs.list.append()或insert()，别直接赋值this.listData = []
list组件里如何做下拉刷新和上拉加载
nvue的list不内置refresher-enabled，得手动监听scrollbottom和scrolltop事件，配合refresh组件实现。关键点在于：刷新状态要靠refresh组件控制，而不是自己写loading遮罩。
Element Plus Vue3 桌面组件库。在开发 Vue 3.x 页面时调用，使用 Element Plus 组件（如 el-button、el-input、el-form、el-table 等）。
立即学习“前端免费学习笔记（深入）”；
- 下拉刷新需包裹
<refresh></refresh>节点，且list必须设show-scrollbar="false"，否则滚动条会干扰下拉手势 - 上拉加载监听
scrollbottom事件，但要加防抖：if (this.loading || this.noMore) return，避免重复触发 - 每次append后调用
this.$nextTick(() => { this.$refs.list?.scrollToBottom() })确保滚动到底部（仅需首次加载后调用） - 不要在
cell里放watch或computed，每个cell是独立原生实例，响应式开销会被放大
跨端兼容时nvue页面的边界问题
list只在App端生效，H5和小程序会自动fallback为scroll-view。这意味着你无法在nvue页面里写条件编译来“混用”，必须单独建一套nvue页面专供App使用。很多人试图在同个.vue文件里用#ifdef APP-PLUS切list，结果H5端报错Unknown custom element: <list></list>。
- 正确做法：新建
pages/list/app-list.nvue，并在pages.json中为App单独配置路由 - 数据层保持一致，但渲染层彻底分离——这不是偷懒，而是nvue的设计约束
- 如果项目已上线，切到
list后发现部分样式错位，大概率是用了flex嵌套或position: relative，nvue里只支持绝对定位和固定宽高
最常被忽略的一点：nvue页面里所有cell的高度必须严格一致，哪怕视觉上想做“卡片+分割线”，也要把分割线高度算进height里。动态高度目前无解，别试uni.createSelectorQuery()——它在nvue里返回null。
