先说个场景我在一个移动端管理后台里接van-list做订单列表分页刚把页面写完打开控制台一看接口在页面初始化那一瞬间连着打了好几次而且每次返回的数据都是重复的。第一反应是代码里的load是不是写错了查了半天没发现问题后来才发现是van-list这个组件的运行机制在“作怪”。这个问题的关键词就是van-list、load、触发多次。它几乎每个用过 Vant 的移动端开发者都会踩一次网上能搜到一堆类似提问但很多回答只丢一句“把immediate-check设为false”就完了没讲清楚底层逻辑。这篇博文我把自己的排查过程和解决方案完整写出来包括为什么会触发多次、有哪些常见坑、以及最终怎么稳稳妥妥地接好分页希望对正在被这个问题折磨的人有帮助。1. 先把场景说清楚load事件是怎么被一遍遍触发的1.1 现象复现与初版写法最经典的复现方式是这样的你用 Vant 的 List 组件写了一个最简单的商品列表van-list v-model:loadingloading :finishedfinished finished-text没有更多了 loadonLoad div v-foritem in list :keyitem.id classlist-item {{ item.name }} /div /van-listimport { ref } from vue; const list ref([]); const loading ref(false); const finished ref(false); const onLoad async () { const res await fetch(/api/list, { method: POST, body: JSON.stringify({ page: 1, pageSize: 10 }) }); const data await res.json(); list.value data.list; loading.value false; };你觉得这段代码没问题对吧但打开页面后Network 面板里能看到/api/list在几毫秒内连续请求了两三次更离谱的时候能请求五六次。数据渲染出来后列表内容还是重复的或者有些页数据直接乱了。这个问题的本质不在于你的分页逻辑写得对不对而在于van-list的触发机制和异步回调之间存在一个“检查空隙”。如果你没有真正理解load事件的触发条件就会觉得它像“抽风”一样乱触发。1.2 理解van-list的执行链条van-list的核心原理并不复杂它监听页面滚动当列表底部快要进入视口时触发load事件去加载更多数据。这个“快要进入视口”的判断是有提前量的默认偏移量是offset值为 10也就是当滚动位置距离列表底部不足 10px 时就会触发一次load。关键来了van-list的触发还有一个immediate-check属性默认是true。意思是在组件挂载后它会立即检查一次当前列表内容是否已经填满了可视区域。如果内容没有填满也就是说第一屏的数据都没铺满整个视口它就认为“还需要加载”于是立刻再触发一次load。如果这次load是异步的加载回来的数据依然没撑满一屏它就会继续触发。这就形成了一种“加载 → 检查 → 没满 → 再加载 → 再检查”的循环。每一轮循环之间虽然有时间差但在接口响应极快、数据量又少的场景下看起来就是连续触发了多次请求。另一个关键角色是loading状态。van-list在触发load时自身会尝试把loading置为true并在下一次检查时判断“如果loading为true则不再触发”。但问题是如果你在异步回调里没有严格地把loading重置为false或者你在外部手动修改了这个值就给了它再次触发的机会。1.3 这是设计缺陷吗说实话这不算是组件缺陷更像是设计取舍。van-list本身不知道你的数据什么时候能撑满屏幕它只能根据“当前loading状态 是否到达底部 是否已 finished”这三个信号来判断要不要加载。一旦像上面那样异步逻辑混乱它就表现出“触发多次”的行为。理解了这套判断逻辑你就能针对每一个环节逐一排查。2. 为什么它会停不下来几个高频原因详解2.1 原因一immediate-check在背后“抢跑”很多人不知道immediate-check是做什么的但它恰恰是“进入页面就发请求”甚至“发多个请求”的头号嫌疑犯。immediate-check的作用是在组件初始化完成之后立刻去检查一次是否需要加载。默认值为true是为了照顾那些“一进入页面就要展示完整列表”的场景。对移动端分页列表来说这本来没什么问题因为大多数列表的数据量足够撑满一屏第一次检查发现“满了”就不会继续触发。可如果你的数据量很少比如总共就 5 条数据或者接口还没返回数据时列表是空的那么首次检查就会发现“没满”于是触发一次load。等数据返回列表高度还是不够又会触发下一次检查。一旦网络延迟、组件并发、渲染时机凑在一起就会产生连续多次请求。解决办法也直接如果我的列表数据量本来就不确定或者我希望完全由自己控制首次加载时机我会把immediate-check显式设为falsevan-list v-model:loadingloading :finishedfinished :immediate-checkfalse loadonLoad /van-list设置false之后van-list不会再主动做初始检查load只会在滚动到底部时触发。那么第一屏的数据就需要自己在onMounted里拉取。2.2 原因二loading状态没有正确闭环这个原因最隐蔽。我们来看一个常见写法const onLoad async () { const res await fetchList(); list.value res.data; loading.value false; };如果请求报错、接口超时、或者代码里某处提前return了loading.value false这句就不会执行。van-list拿到的loading一直是true它会一直认为“当前还在加载中不能再次触发”。但有时候你会遇到相反的情况loading已经被外部代码置为false而异步请求还没回来。此时用户滚动了一下van-list发现loading false且未 finished于是马上再次触发load。如果上一个请求还没结束两个请求并发数据返回顺序不同最终列表里出现重复数据或乱序数据。这里最关键的习惯是一定不要把loading的状态管理和业务请求解耦。我建议在onLoad里先做一个防重入判断const onLoad async () { if (loading.value || finished.value) return; loading.value true; try { const res await fetchList(page.value); list.value list.value.concat(res.data); page.value 1; if (list.value.length res.total) { finished.value true; } } finally { loading.value false; } };finally的好处是即使接口报错loading也会被正确复位不会卡死列表。同时入口处的if (loading.value) return可以挡住所有并发触发。2.3 原因三数据量撑不满一屏触发“假死循环”如果你的列表数据只有一两条甚至没有数据那么就算immediate-check设为trueloading也正常复位依然会出现反复触发的情况。因为列表底部始终在视口内van-list永远认为“需要加载更多”。这种情况下要让finished尽快变为true。一个很常见的失误是第一次请求发现没有更多数据时只设置list.value []没有设置finished.value true。于是van-list无限触发load每次都返回空数组页面看起来就像卡死了。正确做法是在拿到接口返回的total或判断“当前页数据不足一页”时直接设置 finishedif (res.list.length pageSize || list.value.length res.total) { finished.value true; }对于一些没有total字段的分页接口还可以用另一种判断方式如果res.list.length 0则代表没有更多数据了同样设置finished.value true。建议同时在列表空数据时渲染一个van-empty空状态至少让用户能看出“没有数据”而不是看到一个白屏的列表区域还在疯狂请求接口。比如这样van-list v-model:loadingloading :finishedfinished finished-text没有更多了 loadonLoad template v-iflist.length 0 div v-foritem in list :keyitem.id.../div /template van-empty v-else description暂无数据 / /van-list2.4 原因四列表key被重置或组件实例被重建还有一种情况是列表本身没什么问题但父组件的渲染导致van-list被重新创建了。比如你在父组件里用了v-if来控制显示区域或者给van-list外层包了一层带有动态key的元素div :keycurrentTab van-list v-model:loadingloading :finishedfinished loadonLoad.../van-list /div当currentTab变化时整个van-list会重新挂载。每次重新挂载都会触发一次初始检查甚至多次触发load。这种情况下你看到的现象是“切换一个 Tab接口就重复请求好几次”但你查列表逻辑本身根本查不出问题。排查方法很简单在onLoad里加一行console.log(load triggered, Date.now())再配合 Vue 组件的onActivated、onMounted日志。如果发现load触发的频率和组件的重建频率一致那问题多半出在父组件结构上。解决办法一般是把列表组件的key稳定下来或者用keep-alive缓存列表状态避免每次切换都重新拉数据。2.5 原因五滚动容器选错导致监听异常van-list默认监听的是window滚动事件。如果你的页面结构里不是整页滚动而是某一个 div 内部overflow-y: auto那么van-list根本监听不到那个 div 的滚动。结果可能有两种列表完全不触发加载因为 window 滚动位置和内部 div 滚动位置不一致导致“已到达底部”的判断出现误判连续触发多次load。这种场景下需要显式指定scroll-target让van-list去监听正确的滚动容器。div refscrollContainer classscroll-container van-list v-model:loadingloading :finishedfinished scroll-target.scroll-container loadonLoad ... /van-list /div注意scroll-target接收的是 CSS 选择器字符串。如果你的滚动容器是通过ref拿到的 DOM 对象也可以用:scroll-targetscrollEl的方式传 ref 对应的变量。但麻烦点在于ref 在van-list挂载前可能还没赋值会报错所以一般推荐用类名选择器更稳。判断你是否需要设置滚动容器看一条即可页面最外层有没有出现“双滚动条”。如果有说明你已经不是整页滚动了van-list默认监听方案八成会出问题。3. 从复现到修复一个完整的实操示例3.1 先做一个能复现问题的页面为了演示排查过程我造了一个简单的订单列表页面接口是本地 Mock 数据延迟 500ms 返回每页 5 条总共 3 页。页面和接口写好后初版代码如下const listData ref([]); const loading ref(false); const finished ref(false); const page ref(1); const onLoad async () { const data await fetchOrders(page.value); listData.value data.list; loading.value false; };这是最典型的“能用但会疯狂触发”的写法。打开页面控制台输出load triggered load triggered load triggered总共 3 条记录请求却发了 3 次而且每次返回的列表都覆盖了上一次的数据。问题在于immediate-check默认true首次检查时空列表没撑满屏幕触发第一次load数据返回后依然不满一屏继续触发第二次、第三次直到列表数据填满可视区域或者finished为true才会停。3.2 修复immediate-check带来的连发如果你希望“进入页面时不要自动加载”而是自己在onMounted里控制首次请求那就把immediate-check设为falsevan-list v-model:loadingloading :finishedfinished :immediate-checkfalse loadonLoad 然后在组件挂载时主动加载第一页onMounted(() { onLoad(); });这个方案有一个隐藏问题onLoad里的loading状态如果先被置为true然后异步请求完成后置为false那么滚动到底部时van-list不会重复触发但如果你在onMounted里手动调用onLoad同时van-list又因为滚动位置触发了一次load就会出现并发。所以依然要保留“入口防重入判断”。如果你不想自己控制首次加载还是想保留immediate-check的自动检查那就要保证onLoad内部逻辑足够稳避免并发。我个人更推荐保留默认的immediate-checktrue但把下面的防重入和状态闭环写好。这样列表在任何情况下都能自动加载不需要手动调用onMounted。3.3 给异步流程加上完整状态闭环不管选哪个方案一个健壮的onLoad必须做到三件事重入保护如果已经在加载中或已经完成后直接丢弃本次触发。分页字段更新每次加载成功后page自增。完成判断当返回数据不足一页或累计达到总数时设置finished true。以我的订单列表为例最终写法是这样的const listData ref([]); const loading ref(false); const finished ref(false); const page ref(1); const pageSize 10; const onLoad async () { if (loading.value || finished.value) return; loading.value true; try { const res await fetchOrders(page.value, pageSize); const newList res.list || []; listData.value listData.value.concat(newList); if (newList.length pageSize || listData.value.length res.total) { finished.value true; } else { page.value 1; } } catch (e) { console.error(加载失败, e); } finally { loading.value false; } };这段代码有几个细节值得展开if (loading.value || finished.value) return;放在最前面把van-list所有的冗余触发都挡在外面。即使同一时间触发了 10 次load也只有第一次能真正进去。newList.length pageSize这个判断是给“接口不返回 total”的后端准备的如果最后一页不足pageSize说明没有更多了。如果接口返回了total就用listData.value.length res.total来做精确判断。page自增放在else里避免最后一页已经完成时还无谓地加一。3.4 关于“先赋值再自增”与“先自增再请求”的取舍不同分页接口风格差异很大有的后端要求传page 1表示第一页有的要求传page 0表示第一页。无论哪种只要保证一个原则就行当前请求用当前 page请求成功后再更新 page。有些同学习惯在onLoad一开始就page.value然后在请求体里用page.value这样页面首次加载时page就变成 2请求的却是第二页数据列表直接跳过第一页。这类问题不是van-list特有的但一旦出现在van-list的多次触发背景下会显得特别乱。我见过有人排查了半天最终发现是page提前自增导致的跳页所以这里单独提醒一下。3.5 完整页面示例整理出一个可以直接跑的最小示例template div classorder-page van-list v-model:loadingloading :finishedfinished finished-text没有更多了 loadonLoad div v-foritem in listData :keyitem.id classorder-item span classorder-name{{ item.name }}/span span classorder-price{{ item.price }}/span /div van-empty v-if!loading listData.length 0 description暂无订单 / /van-list /div /template script setup import { ref, onMounted } from vue; import { showToast } from vant; const listData ref([]); const loading ref(false); const finished ref(false); const page ref(1); const pageSize 10; const fetchOrders async (page, pageSize) { const res await fetch(/api/orders?page${page}pageSize${pageSize}); if (!res.ok) throw new Error(request failed); return res.json(); }; const onLoad async () { if (loading.value || finished.value) return; loading.value true; try { const res await fetchOrders(page.value, pageSize); const newList res.list || []; listData.value listData.value.concat(newList); if (newList.length pageSize || listData.value.length res.total) { finished.value true; } else { page.value 1; } } catch (error) { showToast(加载失败请稍后重试); } finally { loading.value false; } }; onMounted(() { if (listData.value.length 0) { onLoad(); } }); /script这里我把immediate-check保持默认true。onMounted本来没必要写因为immediate-checktrue时组件自己会检查并触发。但加上它有两个好处明确告诉读者“首次应用自己触发”的设计意图如果以后有人把immediate-check改成false不会忘记首次加载。不过要注意如果immediate-checktrue且onMounted里又调用onLoad必须保证onLoad有防重入判断否则会变成“初始化时请求两次”。我这里已经用if (loading.value || finished.value) return挡住了。4. 排坑顺序与排查技巧总结4.1 从现象反推原因先看请求数量遇到“load 触发多次”不要急着改代码先看 Network 面板里的请求数量和时间线。如果请求是几乎同一时间发出来的比如 200ms 内连续 3 个并发的请求多半是并发重入导致优先检查loading状态有没有做好防重入。如果是每隔几百毫秒发一次、且列表一直不满一屏优先怀疑immediate-check和finished没有设置正确。如果是切换页面、切换 Tab 后才触发多次优先检查父组件是不是重建了列表实例。下面是更详细的排查对照表现象核心原因解决方案页面初始化就连续发多个请求immediate-check 触发接口响应快数据不满一屏设置 loading 防重入或设置 immediate-checkfalse 自己控制首次加载滚动到底部时触发两次以上loading 状态没闭环或没有入口防重入onLoad 开头增加 if (loading.value) return并用 finally 复位 loading列表内容很少依然反复请求数据撑不满一屏且 finished 未设置在空列表或数据不足时立即设置 finishedtrue切换 Tab 或父组件渲染后触发多次van-list 被重建稳定列表 key或用 keep-alive 缓存列表组件页面有内部滚动容器加载混乱滚动监听元素错误使用 scroll-target 指定滚动容器接口失败后列表不再触发loading 一直为 true在 catch/finally 中正确复位 loading并用 try...finally 兜底4.2 两个实用调试技巧第一个技巧是在onLoad里打印调用堆栈。有时候你以为load是滚动触发的结果堆栈显示是初始化时触发的这样能快速判断触发来源。const onLoad async () { console.trace(van-list load triggered); // ... };第二个技巧是给van-list加一个ref在 Vue DevTools 里查看它的当前状态。你可以直接看到loading、finished、error这些内部属性。如果进入页面后loading一直为true说明请求卡住或没有正确复位如果loading反复在true/false之间跳动说明并发重入。4.3 高频问题速查为什么我的列表还在反复触发再整理几个边界问题这些是我在实际群里看到别人问得最多的。Q1我把 immediate-check 设为 false 了为什么进入页面还会请求一次因为设置了immediate-checkfalse只是关闭初始化时的自动检查。如果你自己在onMounted里调用了onLoad那当然会请求。如果没有手动调用页面会先显示空白直到滚动到底部才加载。如果你设置了scroll-target且滚动容器初始位置就在底部那同样会触发load。Q2为什么我明明设置了 finishedtrue控制台还是发了一次请求有可能这次请求在finishedtrue之前已经触发了。van-list是在触发load时检查finished状态如果你在请求返回后才设置finishedtrue那么请求发出时finished还是false自然会被放行。解决方法是把“是否可触发”的判断放进业务里比如请求前先判断当前是否已经加载完全部数据。const onLoad async () { if (loading.value || finished.value || noMore.value) return; // ... };Q3我用了 van-tabs 切换van-list 数据总是重复加载怎么办这种情况十有八九是多个页签共用了同一个van-list状态或者是切页时列表组件被销毁重建。建议把每个页签对应的列表数据、页码、loading、finished 状态独立封装成一个usePagingList组合式函数然后用keep-alive保持页面状态function usePagingList(fetcher) { const listData ref([]); const loading ref(false); const finished ref(false); const page ref(1); const load async () { // ... }; return { listData, loading, finished, load }; }这样每个 Tab 实例之间互相独立不会因为另一个 Tab 的加载状态影响当前列表。Q4van-list 里面塞了 van-tabs 或 van-pull-refresh会不会互相影响会。van-pull-refresh的滚动和van-list的滚动监听经常冲突。如果你在外面套了van-pull-refresh同时内部又用了van-list必须保证滚动的是同一个容器并且在刷新完成时重置列表数据到第一页同时把finished重新设为false。否则“下拉刷新”之后van-list可能会因为还停留在“已经加载完毕”的状态而不触发新请求。我一般在下拉刷新的回调里这样做const onRefresh async () { page.value 1; finished.value false; listData.value []; loading.value false; await onLoad(); };4.4 一个小众但坑人的场景列表外层有 transform 动画如果van-list外层是一个带有transform属性的容器比如你做了一个滑入动画、缩放动画那么部分浏览器对getBoundingClientRect()获取到的位置会偏低或偏高van-list计算底部距离时会产生误差从而提前触发甚至连续触发load。这个场景不太好排查因为代码逻辑没问题状态管理也正确唯一能看到的异常就是“动画播放过程中触发了好几次请求”。解决办法通常是动画结束前先给van-list设置一个“禁用加载”的状态动画结束后重新开启或者对触发进行节流保证 500ms 内只允许一次真正的 loading。let lastLoadTime 0; const MIN_LOAD_INTERVAL 500; const onLoad async () { const now Date.now(); if (now - lastLoadTime MIN_LOAD_INTERVAL) return; lastLoadTime now; // ... };这个节流方案可以作为最后一道兜底但我个人不推荐把它当作主要依赖。因为van-list本身的loading和finished状态已经足够解决问题节流加多了反而会影响正常加载的响应速度。5. 沉淀下来的最佳实践踩过几次坑之后我现在接入van-list有一个固定模板无论项目大小都按这个思路走明确滚动容器整页滚动用默认局部滚动配scroll-target。保持loading和finished的语义准确loading只代表“是否正在请求”finished只代表“是否没有更多数据”。在onLoad入口做防重入判断用try...finally兜底。数据不满一页或接口返回空列表时立刻finished true。页面初始化不依赖immediate-check做业务判断而是把它当作“自动加载开关”来用。这套组合下来我再也没被van-list的“触发多次”坑过。其实这类问题的根因大多不在组件本身而在于异步状态管理和滚动容器选型。你只要把状态闭环做好把容器的关系理清van-list还是一个非常好用的无限滚动组件。最后再多说一句排查这类问题最忌“瞎猜”一定要先看请求时间线和loading状态变化再动手改代码。你把现象记录清楚了答案往往自己就浮出来了。