尧图网站开发 
别急着给代码加各种节流先想清楚一件事van-list的load事件为什么会疯狂触发这个问题我在不同项目里至少踩过三次坑每次表现都差不多——页面一进来就连续发好几个请求滚动到底部又发一批甚至上一轮请求没回来下一轮就已经出去了。排查到最后绝大多数都不是组件本身的问题而是你对它的触发机制理解有偏差。这篇文章我就把van-list的加载逻辑、常见误区和一套可以直接抄的解决方案一次性讲透。1. 先搞懂van-list的触发逻辑才不会瞎调1.1 load事件到底什么时候会触发van-list是移动端做滚动加载最常用的组件之一核心逻辑很直白监听滚动当滚动条接近底部时触发load事件然后你在这个事件里去请求下一页数据。但很多人的理解停留在这里一旦出现问题就只能一顿乱试。实际上van-list的触发机制有三道闸门loading状态组件内部必须认为当前没有在加载才会触发下一次load。finished状态组件必须认为数据还没有全部加载完才会继续触发。滚动位置必须满足距离底部小于offset设定值这个距离条件。这三个条件同时满足load才会被触发。van-list在滚动过程中会不断执行一次检查逻辑这个检查不是等滚动停下来才做而是滚动事件触发了就做。也就是说只要这三个条件一直满足它就会一直触发看起来就像停不下来。一个容易忽略的细节是van-list触发load时组件会尝试把loading置为true用来挡住后续触发。但这个置为 true的动作要生效前提是你必须使用v-model:loading做了双向绑定。如果只写了:loadingloading这种单向绑定组件内部的通知传不到你外面的变量上外面的loading永远是false组件就会觉得没在加载啊继续触发于是出现无限调用。1.2 为什么会出现连发和多发我见过最典型的场景有这么几类第一loading状态没有做好闭环。要么忘了加v-model要么在异步请求里没有在合适时机把它复位。组件判断不了你是否在加载只能不断触发。第二首屏内容不足一屏。van-list默认开启immediate-check初始化时如果发现内容填不满屏幕会反复触发load直到内容填满或finished变为true。如果你的接口一次只返回两三条数据页面上就会看到连续好几个请求打出去这是看起来像 bug但其实是预期行为。第三分页参数没有正确更新。比如page值没有在请求成功后自增每次请求拿到的都是同一页数据列表长度没有变化finished永远不能被赋值true于是滚动到底就继续请求形成死循环。第四滚动容器判断错位。van-list默认监听的是页面级别的滚动如果你的列表在一个overflow-y: auto的 div 里而这个 div 本身又是撑满屏幕的存在滚动发生在 div 上而不是 window 上van-list很可能监听不到正确的滚动事件产生怎么划都不触发或一进来就连续触发的诡异现象。用一个电梯门的类比来帮助理解电梯门在关闭前会检测门缝里有没有东西只要有东西就继续开门门就一直开合个不停。这里的门缝就是滚动位置离底部的距离而loading和finished就相当于有没有人在按关门键。你没有把这些状态管住组件只能按照最保守的逻辑继续开门搬货。2. 排查重复触发时要优先核对的五个位置2.1 loading有没有真正实现双向绑定这是出现频率最高的问题没有之一。很多人写代码时意识到要在load事件里控制loading但写法是van-list :loadingloading :finishedfinished loadonLoad 注意这里用的是:loading不是v-model:loading。当组件内部触发load时虽然它想把loading改成true但因为只是单向绑定你外部的loading变量根本收不到这个变化。等滚动检查再次执行时组件看到的仍然是loading false于是又触发一次。正确写法应该是van-list v-model:loadingloading v-model:errorerror :finishedfinished loadonLoad 如果你用的是 Options API 的 Vue 2 项目v-model需要手动处理或者写成:loading.sync。Vant 2 的 List 组件也支持v-model语法用法类似。经验之谈调试这类问题时先打开 Vue DevTools看一下组件实例里loading的值是否会在触发load后自动变成true。如果一直停留在false那大概率就是绑定方式写错了。2.2 finished是不是被忘在角落里了finished的作用是告诉组件数据已经全部加载完了别再触发load了。 有一种常见的误操作是只在onLoad里更新list却从不判断数据是否已经全部加载完成。举个例子你请求第一页拿到了 10 条第二页拿到了 5 条第三页开始返回空数组。这时候如果不判断list.length total或data.length 0然后设置finished true那么滚动到底部时组件仍然认为应该还有数据于是继续触发load接口继续返回空数组列表却一直在请求。这个问题在真机上尤其明显因为网络请求有延迟loading在请求完成后马上被置为false你还没反应过来下一次请求又发出去了。一个比较稳妥的判断逻辑是if (list.value.length total || page.value totalPages) { finished.value true }或者在接口返回的数组为空时直接设置finished true因为多数后端分页接口在下一页没有数据时都会返回空数组。2.3 滚动容器和页面高度对不对van-list对滚动容器的判定比较特殊多数版本默认监听的是 window 的滚动事件。如果你的页面结构是div classpage div classscroll-area van-list loadonLoad.../van-list /div /div其中.scroll-area设置了height: 100vh; overflow-y: auto而.page和body的高度都刚好是 100vh那么真正滚动的是.scroll-area这个 div。但van-list监听的是 window 滚动window 本身根本没动组件自然无法正确判断接近底部这个条件。这种场景下常见的结果有两种一种是完全不触发load页面滚到底也不会加载新数据另一种是 mini 项目里 body 高度大于 100vhwindow 也能滚但滚动的距离和 div 内部不一致导致load触发多次或时机错乱。我处理这个问题时总结了两个方向如果可能尽量让页面主体用 body 自身的滚动也就是页面级滚动。van-list对页面级滚动的兼容是最好的基本不会出问题。如果必须用局部滚动容器可以给滚动容器一个固定高度并让van-list保持在这个容器内然后通过监听滚动容器的scroll事件手动判断是否接近底部再用一个独立的函数去加载数据。注意这种方案下不要再依赖组件的自动触发否则会叠加出重复请求。补充一个小技巧想知道当前页面到底是谁在滚动可以在浏览器控制台执行document.scrollingElement.scrollTop 100然后看页面有没有变化。如果有变化说明是页面级滚动如果没有变化说明滚动发生在某个子元素上。这样就能快速判断滚动容器对不对。2.4 immediate-check带来的首屏连环触发immediate-check默认是true意思是组件初始化后立即检查一次是否需要触发load。这个检查会结合当前列表内容高度来判断——如果内容不足一屏组件会认为应该继续加载数据来填满屏幕于是触发load。加载完之后如果内容还是不足一屏会再次触发直到内容撑满或者finished为true。很多同学看到页面刚加载就发出了五六个请求第一反应是组件坏了其实这是immediate-check的预期行为。解决方式有三种在数据量比较少、单页返回条数不多的情况下把immediate-check设为false让组件不要主动做首屏补全判断。把单页数据量调大一点比如一次返回 20 条避免首屏内容不够。在你的首次请求逻辑里不要只处理第一页数据可以一次性把前几页的数据合并返回减少连续触发的次数。不过我并不建议一味把immediate-check设为false因为如果你确实是做移动端信息流希望首屏能多加载几屏数据那么组件这个自动补全行为其实是有价值的。关键是你要理解它为什么会连续触发而不是因为它连续触发就一刀切关掉。2.5 请求异常和参数更新不及时造成的假重复还有一种多次触发不是组件的问题是接口或参数的问题。接口异常时如果你的onLoad里没有try...catch...finally请求失败后loading可能一直停在true或停在false。停在true会导致之后完全不触发停在false则会导致用户再滚动一下又发起相同的失败请求看起来就像不断在加载但其实每次都在调同一个报错接口。分页参数不自增也是重灾区。很多新手会写const onLoad async () { const res await fetchList(page.value, pageSize.value) list.value list.value.concat(res.data.list) loading.value false }但忘了page.value 1。这种情况下每次请求拿到的都是第一页数据list的长度始终不变finished永远不会为true组件会一直触发load。这种问题从表面看就是列表数据没增长但请求发个没完。我的建议是在onLoad里对分页参数的自增操作和finished的判断放在同一个代码块里确保每次请求成功都同步推进状态。3. 一套能直接抄的van-list加载方案3.1 基础模板Vant 4 Vue 3下面这套代码是我在实际项目里用得很顺的模板已经处理了loading双向绑定、error状态、finished判断和分页自增可以直接复制过去改接口地址使用。template div classlist-page van-list v-model:loadingloading v-model:errorerror :finishedfinished :finished-textfinishedText :offsetoffset :immediate-checkimmediateCheck loadonLoad div classlist-item v-foritem in list :keyitem.id {{ item.name }} /div template #empty div classlist-empty暂无数据/div /template /van-list /div /template script setup import { ref } from vue const list ref([]) const loading ref(false) const finished ref(false) const error ref(false) const page ref(1) const pageSize 10 const total ref(0) // 触发阈值距离底部小于 100px 时触发加载 const offset 100 // 关闭初始化时的自动检查避免首屏不足一屏时连环触发 const immediateCheck false const finishedText 没有更多了 const fetchList async (pageNo, size) { // 这里替换成你的接口请求 const response await fetch(/api/list?page${pageNo}size${size}) const result await response.json() return result } const onLoad async () { // 防御性判断如果已经在加载或已加载完直接返回 if (loading.value || finished.value) return try { const result await fetchList(page.value, pageSize) list.value list.value.concat(result.list) total.value result.total if (list.value.length total.value) { finished.value true } page.value 1 } catch (e) { // 加载失败时显示错误状态用户点击错误提示可重试 error.value true } finally { loading.value false } } /scriptVant 2 Vue 2 的写法差异不大把script setup改成 Options API 的data和methods就行核心逻辑保持一致。3.2 关键参数解释和合理取值有读者可能觉得参数太多记不住我整理了一份速查表按优先级从高到低排列参数作用建议取值v-model:loading控制是否正在加载阻止重复触发必须双向绑定v-model:error控制错误状态显示错误提示建议开启finished标记所有数据加载完成数据全部加载完时设为 truefinished-text全部加载完后的底部文字可选给用户明确提示offset距离底部多少像素时触发加载200~300 比较合适太大会提前加载immediate-check初始化后是否立即检查并触发 load数据不足一屏时建议设为 falsedirection加载方向down或up默认down上拉加载通常不用改offset的取值要结合屏幕高度来看。移动端屏幕高度一般在 600 到 800 像素之间offset设成 300 意味着你才滑到屏幕一半左右它就已经在请求下一批数据了。如果你的接口返回很快用户感知不强但如果接口比较慢可能出现页面数据还没渲染完下一页又回来了的情况。我一般取 100 到 200 之间。3.3 加一个防并发和竞态处理的写法前面提到van-list自身会通过loading状态挡掉一部分重复触发但在异步请求比较慢、用户滚动比较快的场景下还是可能出现并发问题上一次请求还没返回下一次load已经触发两次请求交叉返回导致数据顺序错乱或重复。一个简单有效的做法是在组件外部维护一个请求序号每次load时递增请求返回后判断序号是否还是最新的不是就直接丢弃let requestSeq 0 const onLoad async () { if (loading.value || finished.value) return const currentSeq requestSeq try { const result await fetchList(page.value, pageSize) if (currentSeq ! requestSeq) return list.value list.value.concat(result.list) // 后续状态更新... } catch (e) { if (currentSeq ! requestSeq) return error.value true } finally { if (currentSeq requestSeq) { loading.value false } } }这个方案的好处是即使用户滚动很快触发了多次load只有最后一次请求的结果会被渲染旧请求的结果不会污染列表。代价是实现稍微复杂一点但对列表数据准确性要求高的项目这点复杂度值得。4. 真机调试经验与日志定位技巧4.1 用日志把触发过程拉出来看看遇到load 触发多次的问题不要急着改代码先把现象记录下来。我常用的方式是在onLoad里打印关键状态const onLoad async () { console.log([van-list] onLoad triggered, { loading: loading.value, finished: finished.value, page: page.value, listLength: list.value.length }) // ... }然后在浏览器里打开开发者工具观察 Console 面板里的输出顺序。你会看到两种规律如果loading打印出来一直是false说明双向绑定没生效。如果page值在一串日志中保持不变说明分页自增逻辑写错位置了。如果listLength没有增加但日志一直在刷多半是接口返回的数据为空或数据格式不对。在网络请求面板里还可以看到请求的并发情况。如果出现多个请求几乎同时发出说明loading的挡锁没有即时生效如果请求是串行但很密集说明是滚动触发链路中的状态没有及时复位。4.2 三个真实的假性多次触发案例案例一首屏一口气发了 10 个请求。这是一个真实项目里遇到的列表页一次返回 5 条数据屏幕高度能容纳大约 15 条immediate-check保持默认的true组件在首屏反复触发load去补足高度。排查后确定的修复方案是把immediate-check设为false同时把单页数据量调整到 15 条问题立刻消失。案例二页面滚动在一个 div 里van-list完全不触发但用户从上级页面返回后它突然开始连续触发。这个问题的根因是页面的 body 高度因其他原因发生了变化window 滚动事件被触发了一次加上组件的immediate-check在重新激活时执行了一次检查两个条件叠加导致没有经过正常滚动就触发了多次load。最终通过固定滚动容器为页面级滚动解决。案例三接口偶发超时catch 里只弹了 toast没有处理loading导致报错后loading状态停在true用户再滚动时无法触发新请求。但用户反复上拉下拽页面表现是一直在转圈网络请求却只有最开始那几次。这个不是多次触发而是触发后被卡死同样和状态管理有关。4.3 容易和load多次触发搞混的周边报错搜索这个问题时你可能会看到一些看起来相似但根本不是一回事的报错我列几个常见的帮你区分一下报错信息和 van-list 的关系常见根因Failed to load module script无关前端构建产物路径或静态资源配置问题常见于 Vite 部署后资源地址缺失mitt 多次触发无关事件总线重复监听多半是组件卸载时没有取消监听Cannot load JDBC...间接相关后端数据库连接异常导致列表接口报错前端视觉上表现为加载失败或一直重试global load 事件相关页面里可能有多个地方监听了 load 相关事件需要排查是不是事件冒泡或重复注册看到这些报错时先判断它出现在哪个环节再决定要不要往van-list的方向排查。很多时候问题根本不在这。5. 一些容易被忽略的工程化细节5.1 分页参数设计分页参数设计看似简单但决定了列表的稳定性和扩展性。页码分页是最常见的page从 1 开始每次成功后自增后端根据page和pageSize返回数据。优点是实现简单前端逻辑直观缺点是如果列表中间插入了新数据页码翻页可能出现数据重复或遗漏。适合后台管理系统这种数据变动不剧烈的场景。游标分页则是记录最后一条数据的唯一标识比如lastId每次请求带上这个值后端返回该 ID 之后的数据。它的优势是列表新增数据时不会影响当前滚动位置适合资讯流、评论列表这类实时性较强的场景。我个人的建议是如果后端愿意配合优先使用游标分页如果只能用页码分页那就要在finished判断和加载状态上下更多功夫避免重复数据带来的体验问题。5.2 空数据、失败数据、全部加载完的边界处理列表类组件的边界情况总是最考验代码健壮性的地方。空数据接口返回空数组时直接给用户显示空状态同时设置finished true避免组件继续触发load请求一个不会返回数据的接口。失败数据请求失败时设置error trueVant 会在列表底部显示错误提示用户点击提示可以重新加载。注意重试时要把error先置为false同时手动触发一次加载。有些项目会在失败时直接把error置为true后忘记复位导致之后再怎么点都不触发加载这个坑要小心。全部加载完设置finished true后组件会在底部显示finished-text指定的文案。如果你把文案设成没有更多了用户一目了然。如果忘了设置finished-text加载完之后底部会留白用户可能还在傻等以为页面卡住了。5.3 封装一个通用列表组合式函数当项目里有很多列表页时重复的loading、finished、page、list状态管理会变得很啰嗦。我这里提供一个组合式函数的封装思路你可以根据自己的业务习惯扩展import { ref } from vue export function useList(fetcher, options {}) { const list ref([]) const loading ref(false) const finished ref(false) const error ref(false) const page ref(1) const pageSize options.pageSize || 10 const load async () { if (loading.value || finished.value) return try { const result await fetcher(page.value, pageSize) list.value list.value.concat(result.list) if (list.value.length result.total || result.list.length 0) { finished.value true } page.value 1 } catch (e) { error.value true } finally { loading.value false } } const refresh () { list.value [] page.value 1 finished.value false error.value false load() } return { list, loading, finished, error, load, refresh } }页面里这样用const { list, loading, finished, error, load, refresh } useList(fetchMyList, { pageSize: 15 })模板里的van-list直接绑定返回的状态即可。收益是每次新增列表页你只需要写接口函数和字段映射重复的状态逻辑都在useList里统一处理了。我在实际项目里踩过不少van-list的坑之后最大的感受是这类组件的异常触发绝大多数不是 bug而是开发者和组件之间的状态契约没有对齐。loading、finished、page这三个变量就像一个闭环里的三个齿轮任何一个没有正确转动整个链条都会出问题。调试时最快的路径永远是先把这三个状态打出来看一遍而不是去改offset或者加防抖。最后再分享一个小技巧在页面上临时把loading和finished的值渲染出来肉眼观察它们的变化节奏往往比看控制台日志更直观等逻辑稳定了再删掉。 
别急着给代码加各种节流先想清楚一件事van-list的load事件为什么会疯狂触发这个问题我在不同项目里至少踩过三次坑每次表现都差不多——页面一进来就连续发好几个请求滚动到底部又发一批甚至上一轮请求没回来下一轮就已经出去了。排查到最后绝大多数都不是组件本身的问题而是你对它的触发机制理解有偏差。这篇文章我就把van-list的加载逻辑、常见误区和一套可以直接抄的解决方案一次性讲透。1. 先搞懂van-list的触发逻辑才不会瞎调1.1 load事件到底什么时候会触发van-list是移动端做滚动加载最常用的组件之一核心逻辑很直白监听滚动当滚动条接近底部时触发load事件然后你在这个事件里去请求下一页数据。但很多人的理解停留在这里一旦出现问题就只能一顿乱试。实际上van-list的触发机制有三道闸门loading状态组件内部必须认为当前没有在加载才会触发下一次load。finished状态组件必须认为数据还没有全部加载完才会继续触发。滚动位置必须满足距离底部小于offset设定值这个距离条件。这三个条件同时满足load才会被触发。van-list在滚动过程中会不断执行一次检查逻辑这个检查不是等滚动停下来才做而是滚动事件触发了就做。也就是说只要这三个条件一直满足它就会一直触发看起来就像停不下来。一个容易忽略的细节是van-list触发load时组件会尝试把loading置为true用来挡住后续触发。但这个置为 true的动作要生效前提是你必须使用v-model:loading做了双向绑定。如果只写了:loadingloading这种单向绑定组件内部的通知传不到你外面的变量上外面的loading永远是false组件就会觉得没在加载啊继续触发于是出现无限调用。1.2 为什么会出现连发和多发我见过最典型的场景有这么几类第一loading状态没有做好闭环。要么忘了加v-model要么在异步请求里没有在合适时机把它复位。组件判断不了你是否在加载只能不断触发。第二首屏内容不足一屏。van-list默认开启immediate-check初始化时如果发现内容填不满屏幕会反复触发load直到内容填满或finished变为true。如果你的接口一次只返回两三条数据页面上就会看到连续好几个请求打出去这是看起来像 bug但其实是预期行为。第三分页参数没有正确更新。比如page值没有在请求成功后自增每次请求拿到的都是同一页数据列表长度没有变化finished永远不能被赋值true于是滚动到底就继续请求形成死循环。第四滚动容器判断错位。van-list默认监听的是页面级别的滚动如果你的列表在一个overflow-y: auto的 div 里而这个 div 本身又是撑满屏幕的存在滚动发生在 div 上而不是 window 上van-list很可能监听不到正确的滚动事件产生怎么划都不触发或一进来就连续触发的诡异现象。用一个电梯门的类比来帮助理解电梯门在关闭前会检测门缝里有没有东西只要有东西就继续开门门就一直开合个不停。这里的门缝就是滚动位置离底部的距离而loading和finished就相当于有没有人在按关门键。你没有把这些状态管住组件只能按照最保守的逻辑继续开门搬货。2. 排查重复触发时要优先核对的五个位置2.1 loading有没有真正实现双向绑定这是出现频率最高的问题没有之一。很多人写代码时意识到要在load事件里控制loading但写法是van-list :loadingloading :finishedfinished loadonLoad 注意这里用的是:loading不是v-model:loading。当组件内部触发load时虽然它想把loading改成true但因为只是单向绑定你外部的loading变量根本收不到这个变化。等滚动检查再次执行时组件看到的仍然是loading false于是又触发一次。正确写法应该是van-list v-model:loadingloading v-model:errorerror :finishedfinished loadonLoad 如果你用的是 Options API 的 Vue 2 项目v-model需要手动处理或者写成:loading.sync。Vant 2 的 List 组件也支持v-model语法用法类似。经验之谈调试这类问题时先打开 Vue DevTools看一下组件实例里loading的值是否会在触发load后自动变成true。如果一直停留在false那大概率就是绑定方式写错了。2.2 finished是不是被忘在角落里了finished的作用是告诉组件数据已经全部加载完了别再触发load了。 有一种常见的误操作是只在onLoad里更新list却从不判断数据是否已经全部加载完成。举个例子你请求第一页拿到了 10 条第二页拿到了 5 条第三页开始返回空数组。这时候如果不判断list.length total或data.length 0然后设置finished true那么滚动到底部时组件仍然认为应该还有数据于是继续触发load接口继续返回空数组列表却一直在请求。这个问题在真机上尤其明显因为网络请求有延迟loading在请求完成后马上被置为false你还没反应过来下一次请求又发出去了。一个比较稳妥的判断逻辑是if (list.value.length total || page.value totalPages) { finished.value true }或者在接口返回的数组为空时直接设置finished true因为多数后端分页接口在下一页没有数据时都会返回空数组。2.3 滚动容器和页面高度对不对van-list对滚动容器的判定比较特殊多数版本默认监听的是 window 的滚动事件。如果你的页面结构是div classpage div classscroll-area van-list loadonLoad.../van-list /div /div其中.scroll-area设置了height: 100vh; overflow-y: auto而.page和body的高度都刚好是 100vh那么真正滚动的是.scroll-area这个 div。但van-list监听的是 window 滚动window 本身根本没动组件自然无法正确判断接近底部这个条件。这种场景下常见的结果有两种一种是完全不触发load页面滚到底也不会加载新数据另一种是 mini 项目里 body 高度大于 100vhwindow 也能滚但滚动的距离和 div 内部不一致导致load触发多次或时机错乱。我处理这个问题时总结了两个方向如果可能尽量让页面主体用 body 自身的滚动也就是页面级滚动。van-list对页面级滚动的兼容是最好的基本不会出问题。如果必须用局部滚动容器可以给滚动容器一个固定高度并让van-list保持在这个容器内然后通过监听滚动容器的scroll事件手动判断是否接近底部再用一个独立的函数去加载数据。注意这种方案下不要再依赖组件的自动触发否则会叠加出重复请求。补充一个小技巧想知道当前页面到底是谁在滚动可以在浏览器控制台执行document.scrollingElement.scrollTop 100然后看页面有没有变化。如果有变化说明是页面级滚动如果没有变化说明滚动发生在某个子元素上。这样就能快速判断滚动容器对不对。2.4 immediate-check带来的首屏连环触发immediate-check默认是true意思是组件初始化后立即检查一次是否需要触发load。这个检查会结合当前列表内容高度来判断——如果内容不足一屏组件会认为应该继续加载数据来填满屏幕于是触发load。加载完之后如果内容还是不足一屏会再次触发直到内容撑满或者finished为true。很多同学看到页面刚加载就发出了五六个请求第一反应是组件坏了其实这是immediate-check的预期行为。解决方式有三种在数据量比较少、单页返回条数不多的情况下把immediate-check设为false让组件不要主动做首屏补全判断。把单页数据量调大一点比如一次返回 20 条避免首屏内容不够。在你的首次请求逻辑里不要只处理第一页数据可以一次性把前几页的数据合并返回减少连续触发的次数。不过我并不建议一味把immediate-check设为false因为如果你确实是做移动端信息流希望首屏能多加载几屏数据那么组件这个自动补全行为其实是有价值的。关键是你要理解它为什么会连续触发而不是因为它连续触发就一刀切关掉。2.5 请求异常和参数更新不及时造成的假重复还有一种多次触发不是组件的问题是接口或参数的问题。接口异常时如果你的onLoad里没有try...catch...finally请求失败后loading可能一直停在true或停在false。停在true会导致之后完全不触发停在false则会导致用户再滚动一下又发起相同的失败请求看起来就像不断在加载但其实每次都在调同一个报错接口。分页参数不自增也是重灾区。很多新手会写const onLoad async () { const res await fetchList(page.value, pageSize.value) list.value list.value.concat(res.data.list) loading.value false }但忘了page.value 1。这种情况下每次请求拿到的都是第一页数据list的长度始终不变finished永远不会为true组件会一直触发load。这种问题从表面看就是列表数据没增长但请求发个没完。我的建议是在onLoad里对分页参数的自增操作和finished的判断放在同一个代码块里确保每次请求成功都同步推进状态。3. 一套能直接抄的van-list加载方案3.1 基础模板Vant 4 Vue 3下面这套代码是我在实际项目里用得很顺的模板已经处理了loading双向绑定、error状态、finished判断和分页自增可以直接复制过去改接口地址使用。template div classlist-page van-list v-model:loadingloading v-model:errorerror :finishedfinished :finished-textfinishedText :offsetoffset :immediate-checkimmediateCheck loadonLoad div classlist-item v-foritem in list :keyitem.id {{ item.name }} /div template #empty div classlist-empty暂无数据/div /template /van-list /div /template script setup import { ref } from vue const list ref([]) const loading ref(false) const finished ref(false) const error ref(false) const page ref(1) const pageSize 10 const total ref(0) // 触发阈值距离底部小于 100px 时触发加载 const offset 100 // 关闭初始化时的自动检查避免首屏不足一屏时连环触发 const immediateCheck false const finishedText 没有更多了 const fetchList async (pageNo, size) { // 这里替换成你的接口请求 const response await fetch(/api/list?page${pageNo}size${size}) const result await response.json() return result } const onLoad async () { // 防御性判断如果已经在加载或已加载完直接返回 if (loading.value || finished.value) return try { const result await fetchList(page.value, pageSize) list.value list.value.concat(result.list) total.value result.total if (list.value.length total.value) { finished.value true } page.value 1 } catch (e) { // 加载失败时显示错误状态用户点击错误提示可重试 error.value true } finally { loading.value false } } /scriptVant 2 Vue 2 的写法差异不大把script setup改成 Options API 的data和methods就行核心逻辑保持一致。3.2 关键参数解释和合理取值有读者可能觉得参数太多记不住我整理了一份速查表按优先级从高到低排列参数作用建议取值v-model:loading控制是否正在加载阻止重复触发必须双向绑定v-model:error控制错误状态显示错误提示建议开启finished标记所有数据加载完成数据全部加载完时设为 truefinished-text全部加载完后的底部文字可选给用户明确提示offset距离底部多少像素时触发加载200~300 比较合适太大会提前加载immediate-check初始化后是否立即检查并触发 load数据不足一屏时建议设为 falsedirection加载方向down或up默认down上拉加载通常不用改offset的取值要结合屏幕高度来看。移动端屏幕高度一般在 600 到 800 像素之间offset设成 300 意味着你才滑到屏幕一半左右它就已经在请求下一批数据了。如果你的接口返回很快用户感知不强但如果接口比较慢可能出现页面数据还没渲染完下一页又回来了的情况。我一般取 100 到 200 之间。3.3 加一个防并发和竞态处理的写法前面提到van-list自身会通过loading状态挡掉一部分重复触发但在异步请求比较慢、用户滚动比较快的场景下还是可能出现并发问题上一次请求还没返回下一次load已经触发两次请求交叉返回导致数据顺序错乱或重复。一个简单有效的做法是在组件外部维护一个请求序号每次load时递增请求返回后判断序号是否还是最新的不是就直接丢弃let requestSeq 0 const onLoad async () { if (loading.value || finished.value) return const currentSeq requestSeq try { const result await fetchList(page.value, pageSize) if (currentSeq ! requestSeq) return list.value list.value.concat(result.list) // 后续状态更新... } catch (e) { if (currentSeq ! requestSeq) return error.value true } finally { if (currentSeq requestSeq) { loading.value false } } }这个方案的好处是即使用户滚动很快触发了多次load只有最后一次请求的结果会被渲染旧请求的结果不会污染列表。代价是实现稍微复杂一点但对列表数据准确性要求高的项目这点复杂度值得。4. 真机调试经验与日志定位技巧4.1 用日志把触发过程拉出来看看遇到load 触发多次的问题不要急着改代码先把现象记录下来。我常用的方式是在onLoad里打印关键状态const onLoad async () { console.log([van-list] onLoad triggered, { loading: loading.value, finished: finished.value, page: page.value, listLength: list.value.length }) // ... }然后在浏览器里打开开发者工具观察 Console 面板里的输出顺序。你会看到两种规律如果loading打印出来一直是false说明双向绑定没生效。如果page值在一串日志中保持不变说明分页自增逻辑写错位置了。如果listLength没有增加但日志一直在刷多半是接口返回的数据为空或数据格式不对。在网络请求面板里还可以看到请求的并发情况。如果出现多个请求几乎同时发出说明loading的挡锁没有即时生效如果请求是串行但很密集说明是滚动触发链路中的状态没有及时复位。4.2 三个真实的假性多次触发案例案例一首屏一口气发了 10 个请求。这是一个真实项目里遇到的列表页一次返回 5 条数据屏幕高度能容纳大约 15 条immediate-check保持默认的true组件在首屏反复触发load去补足高度。排查后确定的修复方案是把immediate-check设为false同时把单页数据量调整到 15 条问题立刻消失。案例二页面滚动在一个 div 里van-list完全不触发但用户从上级页面返回后它突然开始连续触发。这个问题的根因是页面的 body 高度因其他原因发生了变化window 滚动事件被触发了一次加上组件的immediate-check在重新激活时执行了一次检查两个条件叠加导致没有经过正常滚动就触发了多次load。最终通过固定滚动容器为页面级滚动解决。案例三接口偶发超时catch 里只弹了 toast没有处理loading导致报错后loading状态停在true用户再滚动时无法触发新请求。但用户反复上拉下拽页面表现是一直在转圈网络请求却只有最开始那几次。这个不是多次触发而是触发后被卡死同样和状态管理有关。4.3 容易和load多次触发搞混的周边报错搜索这个问题时你可能会看到一些看起来相似但根本不是一回事的报错我列几个常见的帮你区分一下报错信息和 van-list 的关系常见根因Failed to load module script无关前端构建产物路径或静态资源配置问题常见于 Vite 部署后资源地址缺失mitt 多次触发无关事件总线重复监听多半是组件卸载时没有取消监听Cannot load JDBC...间接相关后端数据库连接异常导致列表接口报错前端视觉上表现为加载失败或一直重试global load 事件相关页面里可能有多个地方监听了 load 相关事件需要排查是不是事件冒泡或重复注册看到这些报错时先判断它出现在哪个环节再决定要不要往van-list的方向排查。很多时候问题根本不在这。5. 一些容易被忽略的工程化细节5.1 分页参数设计分页参数设计看似简单但决定了列表的稳定性和扩展性。页码分页是最常见的page从 1 开始每次成功后自增后端根据page和pageSize返回数据。优点是实现简单前端逻辑直观缺点是如果列表中间插入了新数据页码翻页可能出现数据重复或遗漏。适合后台管理系统这种数据变动不剧烈的场景。游标分页则是记录最后一条数据的唯一标识比如lastId每次请求带上这个值后端返回该 ID 之后的数据。它的优势是列表新增数据时不会影响当前滚动位置适合资讯流、评论列表这类实时性较强的场景。我个人的建议是如果后端愿意配合优先使用游标分页如果只能用页码分页那就要在finished判断和加载状态上下更多功夫避免重复数据带来的体验问题。5.2 空数据、失败数据、全部加载完的边界处理列表类组件的边界情况总是最考验代码健壮性的地方。空数据接口返回空数组时直接给用户显示空状态同时设置finished true避免组件继续触发load请求一个不会返回数据的接口。失败数据请求失败时设置error trueVant 会在列表底部显示错误提示用户点击提示可以重新加载。注意重试时要把error先置为false同时手动触发一次加载。有些项目会在失败时直接把error置为true后忘记复位导致之后再怎么点都不触发加载这个坑要小心。全部加载完设置finished true后组件会在底部显示finished-text指定的文案。如果你把文案设成没有更多了用户一目了然。如果忘了设置finished-text加载完之后底部会留白用户可能还在傻等以为页面卡住了。5.3 封装一个通用列表组合式函数当项目里有很多列表页时重复的loading、finished、page、list状态管理会变得很啰嗦。我这里提供一个组合式函数的封装思路你可以根据自己的业务习惯扩展import { ref } from vue export function useList(fetcher, options {}) { const list ref([]) const loading ref(false) const finished ref(false) const error ref(false) const page ref(1) const pageSize options.pageSize || 10 const load async () { if (loading.value || finished.value) return try { const result await fetcher(page.value, pageSize) list.value list.value.concat(result.list) if (list.value.length result.total || result.list.length 0) { finished.value true } page.value 1 } catch (e) { error.value true } finally { loading.value false } } const refresh () { list.value [] page.value 1 finished.value false error.value false load() } return { list, loading, finished, error, load, refresh } }页面里这样用const { list, loading, finished, error, load, refresh } useList(fetchMyList, { pageSize: 15 })模板里的van-list直接绑定返回的状态即可。收益是每次新增列表页你只需要写接口函数和字段映射重复的状态逻辑都在useList里统一处理了。我在实际项目里踩过不少van-list的坑之后最大的感受是这类组件的异常触发绝大多数不是 bug而是开发者和组件之间的状态契约没有对齐。loading、finished、page这三个变量就像一个闭环里的三个齿轮任何一个没有正确转动整个链条都会出问题。调试时最快的路径永远是先把这三个状态打出来看一遍而不是去改offset或者加防抖。最后再分享一个小技巧在页面上临时把loading和finished的值渲染出来肉眼观察它们的变化节奏往往比看控制台日志更直观等逻辑稳定了再删掉。