🧠 Vue 懒加载实践：为什么使用 IntersectionObserver + Promise？它解决了哪些性能问题？

梦语花
242 阅读4分钟

📌 背景介绍

在现代 Web 开发中，页面性能优化是一个非常重要的课题。尤其是在数据量大、内容多的场景下（如报表系统、商品列表页、图片墙等），如果所有内容都在页面初始化时一次性加载完成，会导致：

  • 页面加载速度慢；
  • 用户体验差；
  • 流量浪费（尤其是移动端）；
  • 服务器压力大；

为了解决这些问题，我们引入了 懒加载技术（Lazy Load） 。

🧩 示例解析：懒加载 + 动态渲染

以下是我们要分析的核心组件结构：

vue
深色版本
<template>
  <div class="container w200px h400px mb20px bg-red">
    <!-- 使用 v-has-views 指令实现懒加载 -->
    <div v-has-views="{ threshold: 0.5, Lazy: true, callback: handleImageLoad }">
      {{ dataList }}
    </div>
  </div>
</template>

<script setup>
import { ref } from 'vue';

const dataList = ref('');

function fetchData() {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const success = true;
      if (success) {
        resolve({ data: '这是从服务器获取的数据', status: 200 });
      } else {
        reject(new Error('无法获取数据'));
      }
    }, 500);
  });
}

const handleImageLoad = async (flag) => {
  if (flag) {
    const res = await fetchData();
    dataList.value = res.data;
  }
}
</script>

✅ 核心功能点：

技术功能
v-has-views 指令判断元素是否进入视口
IntersectionObserver API实现懒加载逻辑
Promise 异步请求模拟真实数据获取过程
ref 响应式绑定数据变化自动更新视图

🔍 为什么要用 IntersectionObserver？

传统的判断元素是否可视的方法是通过 window.scroll + getBoundingClientRect() 来实现的。但这种方式存在两个严重问题：

❌ 缺陷：

  1. 频繁触发 scroll 事件，性能开销大
  2. 需要手动管理监听器和节流机制

而 IntersectionObserver 是浏览器原生提供的 API，专门用于监听一个元素与视口或父容器的交叉状态，具备以下优势：

优势描述
高性能不依赖 scroll 事件，由浏览器内部优化
简洁易用只需注册一次观察器即可监听多个元素
支持阈值控制可设置元素多少比例可见后才触发回调

💡 为什么要封装成自定义指令？

Vue 的核心理念之一就是“关注分离”。把懒加载逻辑封装成自定义指令 v-has-views，有以下好处：

✅ 优点：

好处描述
复用性强在任意组件中都可以直接调用 v-has-views
逻辑解耦模板层不关心实现细节，只负责绑定行为
易于维护如果未来要换方案，只需修改指令一处
生命周期可控可以在 mounted 和 unmounted 中处理资源回收

🚀 为什么要用 Promise + async/await？

在这个示例中，我们模拟了一个异步请求 fetchData，并通过 async/await 实现异步流程控制。

✅ 为什么这样设计？

  • 模拟真实网络请求：延迟加载数据，模拟真实业务场景。
  • 避免阻塞主线程：异步操作不会影响页面正常渲染。
  • 可扩展性好：后续可以轻松替换为真实的 API 请求。
  • 清晰的错误处理：可以通过 .catch() 或 try/catch 控制异常流程。

🎯 解决了什么问题？

问题解决方式效果
页面加载慢懒加载未展示的内容提升首屏加载速度
内容冗余加载只加载用户能看到的部分减少不必要的请求
代码重复复杂封装成指令复用提高开发效率
用户体验差按需加载内容更流畅的交互体验

🧩 应用场景举例

这个懒加载方案非常适合以下几种场景：

场景说明
图片墙、商品列表只有图片进入视口才加载真实地址
表格/报表页滚动到底部再加载下一页数据
视频/音频播放器用户滚动到视频区域后再加载资源
动态表单子表或复杂字段按需加载

📦 拓展：结合 DmoBox 渲染报表列表

在完整页面中，你可能看到类似这样的结构：

html
深色版本
<ul>
  <DmoBox></DmoBox>
  <DmoBox></DmoBox>
  <DmoBox></DmoBox>
  <!-- 循环生成多个卡片 -->
</ul>

每个 <DmoBox> 组件都可以使用 v-has-views 指令，确保只有当用户滚动到该卡片位置时，才会发起网络请求并显示具体内容，从而大大提升整体性能。

✅ 总结：这种写法的价值在哪？

价值维度说明
性能优化按需加载减少初始请求，加快首屏渲染
代码结构指令封装让逻辑清晰，易于复用
用户体验内容随滚动逐步展现，交互更自然
可维护性所有懒加载逻辑统一管理，便于后期升级

🚀 后续建议优化方向

如果你希望进一步完善这套懒加载系统，还可以考虑：

  • 添加 loading 状态提示；
  • 加入错误重试机制；
  • 对加载失败的元素做兜底处理；
  • 结合骨架屏（Skeleton Screen）提升体验；
  • 支持动态配置加载阈值（threshold）；
  • 自动取消未完成的异步请求（AbortController）；

如果你正在开发一个低代码平台、报表系统、或是企业级管理系统，这种懒加载方案是非常实用且高效的。希望这篇文章能帮助你理解背后的设计思路，并应用到实际项目中！

如需我帮你封装成完整的懒加载组件库、或提供 Vue3 + Vite + UnoCSS 的模板工程结构，也可以继续提问 😊

avatar
文章
阅读
粉丝