这个问题我太熟悉了。去年我在一个电商项目的商品列表页就踩过这个坑当时也是虚拟列表图片瀑布流用户反馈滚动的时候图片一直在跳运营还以为是机型兼容问题最后定位到就是我们自己实现虚拟列表的方式有问题。如果你也在写 uniapp 的虚拟列表并且遇到了图片上下闪烁这篇内容基本能帮你在半小时内定位到根因并且找到合适的修法。先说结论绝大多数上下闪烁不是 uni-app 框架的 bug而是虚拟列表的 item 复用机制和图片异步加载之间产生了竞争。简单来说列表在滚动时把旧的 item 组件实例直接给了新的数据图片组件的 src 变了但旧图还没完全销毁、新图还没加载出来渲染层就会在显示旧图残留和显示空白/占位之间切换肉眼看就是上下闪跳。1. 虚拟列表的 item 复用到底干了什么一眼看穿闪烁机制虚拟列表的核心思路很朴素只渲染可视区域内的那几条数据滚动的时候动态更新数据而不是把所有几千条数据全部渲染进 DOM。在 uniapp 里这种机制通常靠两种方式实现一种是用现成的插件比如virtual-list、z-paging内部的分页加载方案另一种是自己用 scroll-view 配合计算滚动偏移量然后动态切 slice 渲染。不管用哪种方式只要一旦走到滚动时不断替换列表项数据这条路所有基于组件复用的实现都共享同一个隐患组件的生命周期不会被完全重置。举个例子。假设你的可视区能放 6 个卡片你的虚拟列表底层维护了 10 个 item 占位来保证缓冲。当你从第 1 屏滚到第 2 屏时第 1 屏的 item 并不会销毁而是被重新赋值变成了第 7 条、第 8 条……的数据。在 Vue 2 / Vue 3 里这体现为 data 变化触发组件更新在渲染层uniapp 会把这一块的 wxml 更新成新数据。问题就在这里图片是个异步资源。src换成了新地址但渲染层不是瞬间就能把新图显示出来的——它要先发请求、等响应、解码、合成。在这段时间内控件上保证你能看到的内容分三种情况如果图片的 mode 是 widthFix 之类需要根据加载后的尺寸调整布局的属性旧图还没从画面上移除新图又没加载完布局就会先按默认尺寸渲染图片产生了位移如果之前的 item 复用了图片组件本身并没有重置状态旧图的最后一帧还残留在 GPU 层新图的加载进度却是 0渲染线程就会在旧图帧和新图首帧之间出现视觉跳变如果图片尺寸不一致且外层容器是 flex 布局旧图撑开的高度一瞬间收缩回默认值下一瞬再被新图撑开这就直接表现为上下闪烁。你去看那些出问题的视频录屏基本都是来回上下小幅跳动而不是整块白屏。因为图片组件一直在只是内部画面在切换。清楚了原理排查起来就好办了。先把问题归类是图片资源本身慢还是 item 复用导致的重建冲突还是布局高度在图片加载前后不同步。下面这个排查链路是我实测下来最快的一套按顺序做不需要一上来就动大刀改代码。1.1 用固定高度先把布局跳动隔离掉第一步在虚拟列表项的图片外层套一个固定高度的容器比如view固定高度 180pximage 的 mode 使用 aspectFill。固定容器高度后布局不会因为图片加载前后尺寸不一致而重新排版。这一步不是最终解法但是一个很有用的隔离手段如果固定高度后闪烁消失说明你的闪烁根源在布局异步高度计算如果还在闪说明问题出在组件复用/渲染层。我的建议是先在开发者工具里试切换成微信小程序模式然后真机预览再试一次。开发者工具里很多渲染问题会被掩盖真机才是真实的渲染情况。1.2 检查图片请求是不是每次都重新发起了打开开发者工具的 Network 面板或者微信小程序调试器的 Network滚动列表看图片请求是不是同一张图反复请求。如果发现重复请求说明你的 item 更新机制导致了 vue 组件重新渲染并且 image 组件没有被正确复用其内部缓存。虚拟列表场景下比较容易被忽略的一点组件实例虽然复用了但因为 src 变化触发的是属性更新渲染层通常不会走完整的创建销毁流程但是网络层可能重新发起图片请求。如果你用的是一个自定义组件包裹的 image并且组件内部 watch 了 src 的变化也可能会额外触发加载逻辑。针对重复请求的问题常见修法是在图片地址上做拼接时保持稳定另一个是使用 image 的 lazy-load 属性。不过 lazy-load 只对长列表的首屏优化有意义对已经渲染出来的 item 作用不大。1.3 逐条去掉属性确认是不是某个 setData 触发的大范围更新虚拟列表性能杀手往往在滚动时频繁 setData。如果你的虚拟列表实现在滚动事件里每次 setData 传了全部列表数据或者传了很大一个对象会导致渲染层整体 diff 成本升高图片组件哪怕没变也可能被波及。排查方式在滚动处理函数里把传给 setData 的数据缩减到只包含当前可视区变化的字段。如果图片闪烁频率明显下降说明核心问题是 setData 频率和范围太大需要结合下面的方案来优化。1.4 终极试验换成不复用 list-item 的原生 scroll-view 对比为了确认问题到底是不是虚拟列表导致可以做一个最直接的对照实验不用虚拟列表直接 v-for 渲染所有数据然后滚动对比。如果图片不闪了几乎可以断定就是虚拟列表复用机制在作祟如果图片还是闪那可能是图片加载本身或样式布局的问题。这一步建议保留实验代码作为排查结论记录很多时候半天排查不出来就是因为混在一起看。2. 真正解决图片闪烁的四种方式从稳定复用入手而不是无脑刷新明确了复用机制和图片加载之间有冲突之后要做的不是禁用虚拟列表而是让虚拟列表的复用过程对图片更友好。下面这四种方案按推荐顺序排列你可以根据自己的列表复杂度选择。2.1 方案 A给虚拟列表的每一项设置稳定且可预判的 key这是最基本但非常容易出错的一步。很多虚拟列表插件默认用 index 作为 key但滚动复用时 index 会变导致 Vue 对同一块组件实例的识别错乱进而可能触发组件销毁重建。用 index 做 key在小数据量下没事一旦滚动快就会加剧图片闪烁。正确做法是给每个 item 绑定数据本身的唯一 id比如商品 id、内容 id。这样组件在数据变化时Vue 可以精确复用同一实例而不是先销毁再重建。// 错误示范直接用 index 当作 key view v-for(item, index) in visibleList :keyindex image :srcitem.cover modeaspectFill / /view // 推荐做法使用数据的唯一 id view v-foritem in visibleList :keyitem.id image :srcitem.cover modeaspectFill / /view如果你用了第三方虚拟列表组件并且组件内部已经写死 index key可以试着 fork 一份源码改掉 key 字段通常这一处修改就能让闪烁明显改善。2.2 方案 B图片组件独立封装稳定内部状态把 image 封装成一个自定义组件让 item 里的图片渲染逻辑独立。这样做的一个额外好处是减少 item 内部无意义的依赖比如 item 里其它字段频繁变化时图片组件可以单独在内部做一层拦截只有 src 真正变化时才去更新。封装组件时有一个细节值得注意内部不要直接用 src 作为 image 的 :src 绑定用一个 computed 或者 watch 拦截一下。如果 src 没变就不重新赋值给内部 image。这是减少重复加载请求的最有效手段之一。template image :srcrealSrc modeaspectFill :lazy-loadtrue /image /template script export default { name: StableImage, props: { src: { type: String, default: } }, computed: { realSrc() { // 如果图片地址需要拼接参数可以在这里统一处理 // 并保证同一个资源路径的拼接结果稳定不变 return this.src } } } /script封装完以后还需要配合图片缓存策略。h5 端浏览器本身有 HTTP 缓存小程序端 image 组件也有一定的缓存能力但为了减少闪烁更好的做法是给图片地址拼接一个稳定版本号保证同一张图在缓存有效期内不会因 URL 变化而重新加载。2.3 方案 C用占位背景技巧覆盖新图加载中的空白期如果闪烁的根源是加载间隙暴露了底层背景色那么通过给图片容器设置一个背景占位比如浅灰色块或本地 base64 小图可以大幅减少视觉上的跳变。具体做法是image 的父容器设一个 background-colorimage 本身设一个透明的占位图。加载过程中用户看到的是稳定的占位色块而不是旧图突然消失的空白。配合这个技巧还可以用 image 的show-menu-by-longpress之类的属性做扩展但主要的核心还是让图片容器的高度是稳定的。如果你的列表是高度不等的瀑布流占位背景再配合预计算的高度占位基本能消灭上下闪烁中上下的部分。比如接口返回的数据里有时会带图片宽高比就先用宽高比算出渲染高度而不是等图片加载完再撑开容器。2.4 方案 D控制 item 复用的触发条件减少无谓的 setData虚拟列表最常见的丑陋实现是每次滚动都 setData 整个可视区列表。控制触发频率通常有三个思路节流滚动过程中每 16ms 或 32ms 才更新一次可视区错峰渲染通过计算把即将进入可视区的 item 提前渲染但图片组件延迟赋值 src分层渲染图片列表和文本信息分离文本数据实时更新图片组件只在真正需要显示时才更新。就实际体验而言节流的效果最直接。比如把 scroll-view 的scroll事件处理函数里加一个节流函数保证 100ms 内最多触发一次可视区列表更新。副作用是滚动过程中列表内容的更新会有轻微延迟但不影响使用。let ticking false function onScroll(e) { if (ticking) return ticking true setTimeout(() { updateVisibleList(e.detail.scrollTop) ticking false }, 100) }这个方案适合列表数据量大、但滚动要求不是极高帧率的场景。如果你的业务明确要求非常流畅的滚动可能还需要配合原生渲染。3. 从原理层面深入为什么 uniapp 里这个闪烁比普通 H5 更明显你可能会想同样的问题在纯 H5 里用虚拟列表是不是也这样答案是H5 也会闪但 uniapp 的跨端渲染机制会让闪烁被放大。这里涉及 uniapp 双线程模型的特点。3.1 渲染层与逻辑层分离带来的双线程延迟在微信小程序端的 uniapp 项目里逻辑层运行在 JSCore渲染层运行在 WebView两者通过 setData 通信。这意味着你的虚拟列表数据更新要经过一次跨线程的数据传输。图片资源的加载却是渲染层直接发起的。当 item 复用被触发逻辑层把新数据传给渲染层渲染层更新 image 的 src。这个更新和图片资源加载之间天然存在更长的延迟窗口。在纯 H5 里vue 直接操作 DOM虚拟列表滚动时图片资源加载和 DOM 更新的时序窗口更短闪烁在视觉上就没那么明显。这也是为什么很多人在 H5 端测试时觉得没问题啊一上微信小程序就原形毕露。3.2 image 组件的 mode 属性对布局高度的影响image 组件的 mode 对闪烁的贡献度极高。widthFix模式是指定宽度后高度根据图片真实宽高比自动撑开。这个模式非常依赖图片加载完成后的真实尺寸信息。虚拟列表的场景下如果 item 复用后新图片还没加载完成image 就没有真实宽高信息此时渲染层只能把这个元素当成高度 0 或默认高度处理。于是你会看到滚动时图片所在容器高度突然塌陷然后新图加载完又撑开上下跳动的幅度被放大。解决思路已经提过要么外层固定高度要么用接口返回的宽高比预占位。这里补充一个细节——image 组件里如果设置了lazy-load它在屏幕外不被加载进入屏幕内才加载这在虚拟列表里可能造成滚动到可视区才加载然后图片跳变的现象。所以虚拟列表场景不建议过度依赖 lazy-load而是用预加载策略。3.3 图片缓存策略跨端差异小程序和 App 不一样微信小程序端图片如果 URL 没变化重新渲染 image 不一定重新走网络但有的时候 WebView 的缓存策略不稳定App 端如果是 vue 页面则走的是 WebView 渲染图片缓存逻辑又和 H5 类似如果是 nvue 页面那渲染层是原生视图图片组件是原生 image行为又不同。这里有一个值得整个团队对齐的规范图片 URL 必须设计成稳定可缓存的。不要把时间戳或者随机数拼到图片地址里否则你在任何端都会加剧闪烁。如果你发现同一张图片在滚动过程中反复发请求首先要检查的也应该是图片URL是否稳定。其次再考虑是不是 image 组件被销毁重建。4. 实践案例一个商品瀑布流列表的完整修复过程前面讲了一堆原理我拿一个实际案例把整条思路串起来。这个案例是当时我们项目里一个带货类小程序的商品瀑布流列表虚拟列表实现用的是社区比较流行的组件滚动时图片上下闪烁线上反馈很集中。4.1 初步观察闪烁只发生在快速滚动和慢速滚动停止前测试后发现一个规律慢速一点点滚基本不闪快速一划到底闪烁特别明显。这说明问题不是所有场景都在而是和滚动速度、数据更新频率强相关。我的判断是快速滚动时可视区列表更新的频率极高item 复用的触发也极其频繁图片资源加载跟不上渲染层的更新节奏。慢速滚动时每次只更新一两个 item图片加载有足够时间完成闪烁自然不明显。4.2 检查插件源码发现 key 用的是 index打开插件源码扫了一眼果然虚拟列表内部在渲染 item 时用的是:keyindex。虽然这种写法在很多固定高度列表里问题不大但在商品瀑布流场景里item 高度不一图片和标题混排key 不稳定会导致 Vue 对组件复用判断出现偏差。改法是直接在插件源码里给 key 换成 item 的 id。由于项目里商品 id 是唯一的替换后快速滚动场景的闪烁明显减少但没有完全根治。4.3 继续追踪发现图片高度塌陷是残留闪烁的主因为什么还没根治继续排查后发现商品卡片里图片高度是完全依赖widthFix撑起来的。快速滚动时item 复用的瞬间还没有新图尺寸容器高度塌缩成 0然后再被撑起来。这个塌缩-撑开过程就产生剩余的视觉闪烁。最终方案是给商品卡片里的图片外层容器固定了一个宽高比容器比例根据接口返回的图片宽高比动态计算但计算完成后容器高度就不再变化。这里有个细节值得记录不能简单地给所有图片统一一个固定高度因为商品图比例不一样会导致部分图片显示被裁切。正确做法是响应式地动态计算高度一旦计算出来就用 style 绑定到容器上让 image 在内部填充。view classgoods-cover-wrap :style{ height: coverHeight } image :srcitem.cover modeaspectFill classgoods-cover/image /viewcoverHeight的计算逻辑是coverWidth / item.imageRatio。接口返回里如果有 ratio 就直接用没有的话可以先用一个默认值等图加载完再微调。4.4 最终效果闪跳率下降约 90%剩余边缘情况通过占位色控制改造完后真机滚动测试快速滑动基本看不到跳动了。剩下 10% 的边缘情况出现在弱网环境新图加载时间特别长图片位置会在加载中显示背景色块不过因为高度已经固定视觉上只是图片从色块换成图的过渡不再是上下跳动。如果你也遇到类似的弱网边缘问题可以把背景色设成图片主色调的近似色或者加一个非常细的淡入动画观感会顺滑很多。不过注意如果你的项目使用 nvue动画实现方式不同需要额外适配。5. 避坑经验汇总我做虚拟列表图片优化这几点踩得最深写到这里我把整个调试过程中踩过、见过以及在社区里反复被提到的坑统一列出来当成一个备忘录吧。5.1 不要迷信虚拟列表插件开箱即用第三方虚拟列表插件的定位是通用场景不会针对你的图片加载、商品卡片复杂度做专项优化。下载插件后第一件事应该是读源码确认 key 的生成逻辑、复用策略、缓冲区的设置。大部分闪烁问题都藏在源码细节里。5.2 真机测试是第一优先级不要在开发者工具里反复纠结这一点真的是血泪教训。开发者工具里的渲染环境是模拟的很多时序问题根本复现不出来。我在开发者工具里调了很久一度以为已经修好了结果真机一测原形毕露。所以建议流程是先在开发者工具里把明显逻辑问题修掉然后立刻上真机尤其是安卓低端机的微信小程序环境闪烁在低端机上更容易暴露。5.3 图片大小和格式对加载速度的影响往往被忽略同样的一个列表图片 100KB 和图片 500KB 的加载速度差很多。虚拟列表场景下图片加载速度直接影响闪烁概率。如果项目里的图片资源可以在上传时压缩尽量压到 100KB 以内格式优先 WebP 或采用服务端图片处理参数。我当时给运营定了规则商品图最大宽度 750px质量 80%WebP 优先。这个操作本身没有增加开发量但对图片闪烁体验的提升是肉眼可见的。5.4 关于预加载和虚拟列表的配合预加载不要过度设计。最简单的做法是在列表滚到倒数第二条数据时就提前加载下一屏图片。不一定要用独立的预加载管理器在 item 组件内部对即将出现的 src 触发一个 new Image() 请求就可以。但注意预加载要用在用户明显即将看到的区域乱预加载大量图片反而会让网络拥堵导致当前屏图片加载变慢闪烁更严重。5.5 微信小程序分包体积超限时不要把图片 base64 进包这个坑和标题相关但容易走偏。有些开发者为了省图片请求把一些小图标 base64 进代码里一旦分包超过 2MB 限制又开始删减。其实虚拟列表里的图片尽量走网络 URL不要把图片资源打进包里对体积和加载体验都是负优化。5.6 有条件的话优先考虑 nvue 的原生列表如果你的虚拟列表性能要求特别高而且图片闪烁已经到了不可接受的程度可以考虑使用 nvue 页面 list组件。nvue 走的是原生渲染图片组件是原生 image虽然也有加载时序问题但不再经过双线程 setData闪烁出现的概率低很多。代价是 nvue 的样式支持有限不能完全复用 vue 页面的样式需要单独写一套适配。如果你的项目首页或核心列表页性能是命根子这个成本是值得投入的。6. 还可以这样进一步优化把加载体验做成预期内的事修完闪烁之后如果想进一步提升体验还能做一件事把图片加载状态的呈现变成明确的设计。不要指望用户不注意到加载过程而是把加载过程做得顺滑、统一、可预期。一个比较顺滑的标准做法是进入列表图片容器先按设计高度占位骨架屏色块图片加载成功淡入显示背景色块充满期间不跳动图片加载失败显示统一失败占位图不影响布局滚动过程中新图片进入可视区前预加载进入时已经 ready。这一套做好之后用户感知的是稳定的骨架屏平滑的图片出现而不是图片在跳。从实际体验来说这套机制不仅能解决虚拟列表的闪烁还能解决非虚拟列表长列表的图片加载突兀问题项目里可以沉淀成公共组件。需要提醒的是不要给所有页面统一强制用这套组件如果某些页面图片加载本来就快比如本地图、小图过度设计反而增加维护成本。按列表类型决定是否使用是最务实的做法。整体回顾下来虚拟列表图片上下闪烁这个问题本质上不是 uni-app 某个版本独有的 bug而是跨端渲染模型、组件复用机制、图片异步加载三者叠加之后必然出现的产物。搞清楚了这层关系你就不会再纠结要不要换一个虚拟列表组件这类表面问题了而是能顺着原理根据自己的项目量身定做一套稳定的渲染策略。如果这篇内容帮到你了后续你在项目里修类似的渲染时序问题时可以优先考虑用固定高度 稳定 key 图片组件封装这三板斧来试错。这是我在多次实战里被验证过最快见效的组合。