一场“数据海啸”，让我重新认识了 requestAnimationFrame

那是一个普通的下午，我正悠哉地喝着咖啡，准备轻松完成一个"列表渲染"的小需求。后端同事发来消息：

"小王，接口写好了，就几条数据，前端渲染一下就行。"

我点开接口一看，整个人差点从椅子上滑下来：
10 万条数据！

脑子里立刻浮现出一种画面：就像港口突然迎来一艘超级货船，把几十万件货物一股脑儿砸到我面前，而我却只有一辆小推车去搬运。

但我还是硬着头皮上了，写下最直观的循环渲染：

const container = document.querySelector(".list-container");
const dataList = new Array(100000).fill('我是数据项').map((t, i) => `${t} - ${i + 1}`);

for (let i = 0; i < dataList.length; i++) {
  const div = document.createElement('div');
  div.innerText = dataList[i];
  container.appendChild(div);
}

结果毫不意外：

• 浏览器瞬间卡死，鼠标动不了
• 页面白屏，用户完全无法操作
• 内存一路飙升，Chrome 差点崩溃

这就像把全部货物直接砸在港口，结果不仅搬运停滞，还把整个码头压塌了。

1.为什么会这样？

• JS 执行阻塞：创建 10 万个 DOM 节点让主线程无暇他顾
• 渲染延迟：浏览器还没来得及"喘气"，页面就被压垮
• 内存压力：DOM 堆积过多，机器性能直接跪了

我盯着屏幕发呆，心想：

"难道就没有一种方法，可以像分批卸货一样，把这些数据一点点渲染到页面里？"

2.关键时刻的救星：requestAnimationFrame

就在这时，我想起一个被我长期忽视的 API：requestAnimationFrame。

它的特性正好符合我的需求：

• 浏览器会在下一帧渲染前 调用回调（大约 16.6ms 一次）
• 能和刷新频率保持一致
• 不会长时间霸占主线程

于是，我决定换一种思路：分批渲染。

function renderBigData(data, chunkSize = 50) {
  const container = document.querySelector(".list-container");
  let index = 0;

  function renderChunk() {
    const chunkEnd = Math.min(index + chunkSize, data.length);
    const fragment = document.createDocumentFragment();

    for (; index < chunkEnd; index++) {
      const div = document.createElement('div');
      div.innerText = data[index];
      fragment.appendChild(div);
    }

    container.appendChild(fragment);

    if (index < data.length) {
      requestAnimationFrame(renderChunk); // 下一帧继续
    }
  }

  renderChunk();
}

// 测试渲染 1 万条数据
const dataList = new Array(10000).fill('我是数据项').map((t, i) => `${t} - ${i + 1}`);
renderBigData(dataList);

效果瞬间不一样了：

✅ 页面不卡顿，每次只渲染 50 条，主线程得以喘息

✅ 用户依然能点击、滚动、输入

✅ 渲染过程像流水一样自然，不再"一刀切"

---

3.进阶优化：虚拟滚动（Virtual Scroll）

然而，问题并没有结束。

如果数据量达到 几十万甚至上百万条，哪怕分批渲染，DOM 仍然会堆积如山。

这时，真正的"性能核武器"登场了：虚拟滚动。

原理就像"橱窗展示"

• 商场仓库里有 10 万件衣服，但橱窗只摆几十件
• 用户走过来时，再换上他们能看到的那一批

简单代码示例：

function renderVirtualScroll(data, container, itemHeight = 30) {
  const viewportHeight = container.clientHeight;
  const visibleCount = Math.ceil(viewportHeight / itemHeight);
  let startIndex = 0;

  function updateVisibleItems() {
    const endIndex = startIndex + visibleCount;
    const visibleData = data.slice(startIndex, endIndex);

    container.innerHTML = '';
    visibleData.forEach(item => {
      const div = document.createElement('div');
      div.style.height = `${itemHeight}px`;
      div.textContent = item;
      container.appendChild(div);
    });
  }

  container.addEventListener('scroll', () => {
    startIndex = Math.floor(container.scrollTop / itemHeight);
    updateVisibleItems();
  });

  updateVisibleItems();
}

这样，无论数据量有多大，DOM 中真正存在的始终只有几十个元素，性能丝滑无比。

---

4.那么，到底该选哪种方案？

方案	适用场景	优点	缺点
直接渲染	< 5k 条数据	简单粗暴	数据量一大就爆炸
分批渲染 (rAF)	5k ~ 10w 条	页面不卡顿，实现简单	DOM 节点仍很多
虚拟滚动	10w+ 条	性能极致，内存占用低	实现较复杂

---

5.总结

前端性能优化，不只是让代码能跑，而是让用户感到"丝滑"。

如果把数据渲染比作一场货物运输：

• 直接渲染是一次性压港口
• 分批渲染是分车次慢慢运
• 虚拟滚动则是橱窗展示，给你看你需要的

而 requestAnimationFrame，就是那个让运输过程变得优雅、从容的调度员； 所以下次，当你也遇到"数据海啸"时，交给它吧。