用requestAnimationFrame优化JS滚动导航栏变色渲染

作者：白帽猫

时间：2026-10-30

深入讲解如何使用 requestAnimationFrame 结合状态锁优化网页滚动导航栏变色效果，消除高频滚动事件带来的卡顿与重绘开销。

文章目录

页面滚动至特定高度时让顶部固定导航栏变换背景色是现代网站的常见交互。实现这一效果的核心瓶颈不在于计算滚动位移，而在于滚动事件每秒触发数十至上百次，直接在监听回调中读取与修改 DOM 会导致浏览器主线程阻塞与严重的掉帧。本文通过引入 requestAnimationFrame 结合布尔状态锁，将高频滚动监听与浏览器的屏幕刷新周期严格对齐，彻底消除多余重绘，提供丝滑流畅的变色体验。

一、高频滚动与浏览器渲染的内在冲突

当用户在触摸板或滚轮上滑动页面时，浏览器会以极高频率向主线程抛出 scroll 事件。在常规屏幕刷新率为 60Hz 的设备上，浏览器每 16.6 毫秒需要完成一次绘制；而在 120Hz 高刷新率屏幕上，单帧时间窗口更是缩短到约 8.3 毫秒。

如果直接将样式修改逻辑绑定在 window.addEventListener('scroll', callback) 内部，滚动期间每秒可能触发上百次 callback 执行。每一次执行中读取 window.scrollY 或容器的 offsetTop，紧接着又修改 navbar.style.backgroundColor 或 classList，就会导致浏览器在单帧内反复执行“读取几何信息 → 写入样式”，触发强迫同步布局（Forced Synchronous Layout / Layout Thrashing），直接造成肉眼可见的卡顿与滚动撕裂。

图 1：原生频繁事件触发机制与 rAF 垂直同步渲染流水线的效率对比

二、核心机制：阈值划分与状态去重

导航栏变色通常是由“未滚动（透明/轻微投影）”到“已滚动超过阈值（实色背景/深色投影）”的二元状态切换。实现高性能渲染的第一项关键决策是：不要在每一帧中无脑重新修改 class 或 style。

即便使用了 requestAnimationFrame，如果用户持续向下滚动 1500 像素，在超过变色阈值（例如 60 像素）后，后续每一帧判断结果均为“需要变色”。若不断调用 navbar.classList.add('scrolled')，仍然会耗费浏览器去核对类名列表并重新评估选择器。

通过在 JavaScript 内存中维护一个轻量的布尔变量 hasScrolled，记录当前导航栏在视觉上是否已经处于激活状态。只有当用户滚动的实时高度发生跨越阈值的变化、导致 currentStatus !== hasScrolled 时，才真正操作一次 DOM。

图 2：临界阈值判定与内部状态去重逻辑分支

三、实装改造：从结构设计到代码闭环

高质量的性能优化必须遵循“结构、表现与行为分离”的原则。变色动效的颜色渐变、投影和尺寸过渡应当交给 CSS 的 transition 负责，利用 GPU 加速渲染；JavaScript 只承担状态监测与类名分发的控制职责。

1. HTML 与 CSS 样式定义

导航栏固定在页面顶部，通过 CSS 定义默认态与激活态 .is-scrolled。过渡属性限定在 background-color、box-shadow 与 backdrop-filter，切勿过渡 height 或 padding，避免引起重排。

<!-- 顶部导航结构 -->
<header class="navbar" id="siteHeader">
  <div class="navbar-container">
    <a href="#" class="brand-logo">TechNotes</a>
    <nav class="nav-links">
      <a href="#home">首页</a>
      <a href="#articles">技术文章</a>
      <a href="#about">关于</a>
    </nav>
  </div>
</header>

<style>
  /* 默认透明或浅色状态 */
  .navbar {
    position: fixed;
    top: 0;
    left: 0;
    width: 100%;
    height: 64px;
    display: flex;
    align-items: center;
    background-color: transparent;
    color: #FFFFFF;
    transition: background-color 0.3s ease, box-shadow 0.3s ease, color 0.3s ease;
    z-index: 1000;
  }

  /* 滚动超阈值后激活的样式 */
  .navbar.is-scrolled {
    background-color: rgba(255, 255, 255, 0.95);
    color: #394957;
    box-shadow: 0 2px 12px rgba(57, 73, 87, 0.08);
    backdrop-filter: blur(8px);
  }
</style>

2. 编写高性能 requestAnimationFrame 控制逻辑

我们使用一个 ticking 标志位作为锁。当滚动事件发生时，如果 ticking 为 true，说明当前已有尚未绘制的帧任务，新事件直接跳过；如果为 false，则先将锁置为 true，并通过 window.requestAnimationFrame 预约下一次渲染。

/**
 * 导航栏滚动变色控制器
 */
(function setupNavbarScroll() {
  const navbar = document.getElementById('siteHeader');
  if (!navbar) return;

  const SCROLL_THRESHOLD = 60; // 变色临界高度 (像素)
  let isScrolled = false;      // 内存记录：当前导航栏是否处于变色状态
  let ticking = false;         // 渲染锁：标记是否有 rAF 请求正在等待调度

  // 核心样式更新方法：在 rAF 周期内执行
  function updateNavbar() {
    // 兼容各浏览器获取当前纵向位移
    const currentScrollY = window.scrollY || window.pageYOffset || document.documentElement.scrollTop || 0;
    const shouldBeScrolled = currentScrollY > SCROLL_THRESHOLD;

    // 只有状态确实发生反转时才触碰 DOM
    if (shouldBeScrolled !== isScrolled) {
      isScrolled = shouldBeScrolled;
      if (isScrolled) {
        navbar.classList.add('is-scrolled');
      } else {
        navbar.classList.remove('is-scrolled');
      }
    }

    // 绘制任务完成，释放布尔锁，允许下一次 rAF 注册
    ticking = false;
  }

  // 滚动事件处理函数：仅负责申请帧调度
  function onScroll() {
    if (!ticking) {
      ticking = true;
      window.requestAnimationFrame(updateNavbar);
    }
  }

  // 使用 passive: true 声明此监听器不会取消默认滚动，避免阻塞滑动主线程
  window.addEventListener('scroll', onScroll, { passive: true });

  // 页面加载或刷新时主动执行一次，确保初始状态与当前滚动条位置保持同步
  updateNavbar();
})();

图 3：优化方案执行闭环：从事件挂载到渲染完成的四个核心阶段

四、容易忽略的关键细节与边界防御

在实际生产环境中，若只按最基础的思路编写代码，可能会遇到几类较为隐蔽的边界问题：

1. 首屏直接刷新或锚点跳转导致的初始状态失真

用户如果阅读文章到中途刷新页面，浏览器往往会记住滚动条位置并自动回滚到原处。如果代码仅仅在 scroll 事件触发时才执行检测，那么页面加载完毕瞬间，用户视口可能已经位于 800px 处，但导航栏依然显示首屏时的全透明背景。因此，必须在脚本初始化最后显式调用一次 updateNavbar()。

2. 移动端 iOS 弹性滚动（Rubber-Banding）产生的负值位移

在 Safari 等支持橡皮筋阻尼回弹的浏览器中，在页面最顶部下拉时，window.scrollY 可能会取得负数；在页面底部过度下拉时，位移也会超出总文档高度。通过在读取高度时增加简单的边界防御（例如 Math.max(0, currentScrollY)），可以避免负值干扰后续逻辑。

3. 使用 passive 事件监听器保障滚动流畅

现代浏览器在执行滚动事件监听函数时，默认需要等待 JS 执行完毕以确认是否调用了 event.preventDefault()。在监听器选项中加入 { passive: true }，等于明确告知浏览器“本回调绝不阻止原生滚动”，浏览器即可在主线程评估 JS 的同时直接由合成器线程处理流畅滚动。

五、主流滚动优化技术方案对照与选型

优化高频滚动事件除了 requestAnimationFrame 之外，前端常见的方案还包括 lodash.throttle（定时器节流）与 IntersectionObserver（交叉观察器）。选择哪种方案取决于业务需求对交互响应精度和兼容性的要求：

图 4：现代前端滚动优化方案选型与核心特性矩阵

六、结语与实践建议

优化滚动导航栏看似是一个微小的前端细节，但其直接贯穿了浏览器事件循环、渲染流水线与硬件同步机制。使用 requestAnimationFrame 的本质，是把原本由用户输入无序驱动的代码执行，转换为由浏览器渲染节奏有序拉动的协同处理。

在日常开发中，建议牢记三个配合原则：第一，使用 { passive: true } 释放主线程；第二，借助布尔锁避免帧任务堆积，并用内部变量过滤无效的 DOM 重写；第三，让 CSS 负责所有属性的渐变动画，JS 仅承担轻量级的状态切换。遵循这些标准，即可在极低代码开销下获得流畅自然的变色导航栏交互体验。