从LRC解析到scrollTop：手写一个丝滑的歌词滚动效果

最近在做音乐播放器页面的时候，随手写了个歌词滚动效果，本来以为就是“根据音频当前时间把对应歌词行高亮一下”这么简单，真正动手才发现里面藏着一堆细节：LRC时间戳的解析精度、高亮行居中算法、滚动性能和用户手动滑动之间的冲突处理，每一步都能展开讲不少。这篇就把这次练习的完整思路、代码实现和踩坑过程整理出来，给同样想做这块的朋友一个参考。

本文适合三类人看：一是刚接触前端、想拿一个小项目练手的初学者，能从中学会一个完整功能的拆解流程；二是已经在做播放器、K歌类产品，需要把歌词滚动做顺滑的前端开发者，可以直接参考这里的算法和交互方案；三是对音频可视化或者页面动效感兴趣，想看看性能优化怎么落地的朋友。整个项目不依赖任何框架，原生 JavaScript 就能跑，方便你迁移到 Vue、React 里。

1. 拿到歌词文件后，第一道坎是解析LRC

歌词滚动的前提是有结构化的歌词数据。网上能下载到的歌词文件大多是 LRC 格式，也就是带时间戳标记的纯文本。很多人一开始觉得解析 LRC 很简单，用正则把 [mm:ss.xx] 抽出来就行，真做起来才发现有几个坑。

1.1 LRC格式的常见变体和坑

最标准的 LRC 长这样：

code复制[ti:晴天]
[ar:周杰伦]
[00:12.00]故事的小黄花
[00:16.50]从出生那年就飘着
[00:20.00]童年的荡秋千
[00:24.30]随记忆一直晃到现在

第一类是元数据标签 [ti:]、[ar:]、[al:]、[by:]，它们的时间戳位置不是数字，解析的时候要单独过滤。第二类是一行歌词对应多个时间戳，比如：

code复制[00:12.00][01:30.00][02:45.00]副歌部分重复唱这一段

这种情况如果你只取第一个时间戳，那后面两遍副歌就不会高亮。第三类是有些歌词源会带 [offset:] 标签，表示整体时间偏移的毫秒数，正值表示歌词整体提前，负值表示延后，国内大部分播放器其实不处理这个标签，但正规解析器最好支持。

1.2 解析器的设计思路

我的做法是先把每行文本按 ] 拆分成时间标签部分和歌词内容部分，再去逐一匹配时间标签。这样一来，多时间戳的歌词自然会被展开成多条记录，每一条都指向同一句歌词内容。

javascript复制function parseLRC(lrcText) {
  const lines = lrcText.split('\n');
  const result = [];
  const timeTagReg = /\[(\d{1,2}):(\d{1,2})(?:[.:](\d{1,3}))?\]/g;
  let offset = 0;

  for (const line of lines) {
    // 先处理offset标签
    const offsetMatch = line.match(/\[offset:([+-]?\d+)\]/);
    if (offsetMatch) {
      offset = parseInt(offsetMatch[1], 10);
      continue;
    }

    // 提取所有时间戳
    const tags = [...line.matchAll(timeTagReg)];
    if (tags.length === 0) continue;

    const text = line.replace(timeTagReg, '').trim();
    for (const tag of tags) {
      const min = parseInt(tag[1], 10);
      const sec = parseInt(tag[2], 10);
      // 毫秒部分可能只有1位或2位，需要归一化到毫秒
      let msStr = tag[3] || '0';
      if (msStr.length === 1) msStr += '00';
      else if (msStr.length === 2) msStr += '0';
      const ms = parseInt(msStr, 10);
      const timeInMs = (min * 60 + sec) * 1000 + ms + offset;

      result.push({ time: Math.max(0, timeInMs), text });
    }
  }

  // 按时间排序，方便后续二分查找
  result.sort((a, b) => a.time - b.time);
  return result;
}

1.3 毫秒精度比你想象的更重要

LRC 里常见的毫秒写法有 [00:16.5]、[00:16.50]、[00:16.500] 三种精度。如果你直接 parseFloat(秒数) 去算，16.5 和 16.50 倒是没区别，但有些歌词源会用 [00:16.500] 表示 500 毫秒，用 parseFloat 也没问题。真正要小心的是用 Date 解析或者把小数点当小数点用的时候，出现浮点数累加误差。

我习惯全程用毫秒整数来参与计算，存进数组之后统一是整数毫秒。一来避免浮点数比较的误差，二来后续做 currentTime（秒，浮点）和歌词时间（毫秒，整数）的匹配时换算公式清晰：audio.currentTime * 1000。

这一步做完，你就得到了一份按时间排序的、带毫秒时间戳的歌词数组 lyrics，歌词滚动的所有计算都基于它。很多教程把这一步一笔带过，我反而觉得这是整个项目里最值得细心打磨的部分，因为后面所有滚动逻辑的准确性都建立在解析数据的质量上。

2. 从“当前时间”到“滚多少像素”：核心算法设计

歌词数据准备好了，接下来要解决的核心问题是：给定当前播放时间 currentTime，我到底应该把歌词容器滚动到什么位置，才能让当前句子正好停留在可视区的中间？

2.1 目标行定位：二分查找更稳

常规做法是遍历数组找到最后一个 time <= currentTime 的歌词行，那就是当前应该高亮的行。但如果歌词很长（比如一首 6 分钟的歌曲，LRC 可能有 60~80 行），每 250ms 做一次全数组遍历也还好，不算性能瓶颈。不过在移动端，如果页面里同时有动画和滚动，主线程压力本身就大，能用二分就二分，养成好习惯。

javascript复制function findCurrentLineIndex(lyrics, currentTimeMs) {
  let left = 0;
  let right = lyrics.length - 1;
  let result = -1;

  while (left <= right) {
    const mid = Math.floor((left + right) / 2);
    if (lyrics[mid].time <= currentTimeMs) {
      result = mid;
      left = mid + 1;
    } else {
      right = mid - 1;
    }
  }
  return result;
}

这个函数返回当前应高亮行的索引。注意边界情况：如果 currentTimeMs 小于第一行歌词时间，返回 -1，表示还没到第一句；如果大于最后一行，返回最后一行索引。

2.2 滚动位置的计算：不是简单滚到目标行顶部

假设每行歌词高度固定为 lineHeight，第 index 行的顶部偏移量是 index * lineHeight。如果直接把容器 scrollTop 设为 index * lineHeight，那高亮行会出现在容器最顶部，唱歌时视线一直看着最上面，体验很差。通常我们要让高亮行出现在可视区域垂直居中的位置。

公式是这样：

code复制目标scrollTop = 高亮行顶部偏移量 - (容器可视高度 - 单行高度) / 2

为什么要减去 (容器可视高度 - 单行高度) / 2？因为“居中”的意思是这一行的中心点要和容器可视区域的中心点重合。假设容器高度是 containerHeight，单行高度是 lineHeight，那么可视区域中心到容器顶部的距离是 containerHeight / 2。高亮行中心点距容器顶部为 index * lineHeight + lineHeight / 2。让两者相等：

code复制index * lineHeight + lineHeight / 2 = containerHeight / 2 + scrollTop

这里的 scrollTop 是容器已经滚走的距离，解出来就是：

code复制scrollTop = index * lineHeight + lineHeight / 2 - containerHeight / 2

简化一下，lineHeight / 2 - containerHeight / 2 就是 -(containerHeight - lineHeight) / 2，所以实际用的公式是：

code复制scrollTop = index * lineHeight - (containerHeight - lineHeight) / 2

这个公式有个好处：你把任意一行的索引传进来，都能得到让这一行精确居中的滚动位置。比如容器高度 400px，单行高 40px，那么第 10 行的目标 scrollTop 就是 10 * 40 - (400 - 40) / 2 = 400 - 180 = 220px。

2.3 首尾行的边界处理

如果这首歌开头几句还没唱完，这时歌词列表还没滚动到能让第一行居中的位置，直接套公式会得到负数 scrollTop。浏览器对负 scrollTop 的处理是钳制为 0，所以视觉上不会出错，但如果你在代码里对 scrollTop 做了动画过渡，负值可能导致过渡动画跳变。我的做法是手动做一次钳制：

javascript复制const targetScrollTop = Math.max(0, currentLineIndex * LINE_HEIGHT - (containerHeight - LINE_HEIGHT) / 2);
const maxScrollTop = lyrics.length * LINE_HEIGHT - containerHeight;
const safeScrollTop = Math.min(targetScrollTop, Math.max(0, maxScrollTop));

末尾行同理：如果最后一行歌词滚到居中的位置时，容器已经不能继续滚了（因为底部没有更多内容），那就让它停在最大可滚动位置，保证最后一句不会悬停在中间位置被截断。很多初学者在这里会栽跟头：最后一句歌词始终无法居中，用这个钳制就能解决。

2.4 为什么用 scrollTop 而不是 transform

实现歌词滚动有两种主流方案：改 scrollTop，或者把整个歌词列表放进一个容器里用 transform: translateY() 移动。

我最终选了 scrollTop，核心原因有两个。

第一，滚动是浏览器的原生行为。scrollTop 的修改会同步更新滚动条位置，支持触摸板的惯性滚动、鼠标滚轮、键盘方向键，这些交互在移动端和桌面端都能一致工作。而 transform 方案等于自己造了一个滚动容器，你要额外处理滚动条显示、触摸事件、滚轮事件，复杂度成倍上升。

第二，用户手动滚动时，浏览器的滚动机制会自动调整 scrollTop，这个值和我们用程序控制的目标值是同一个坐标系，互相覆盖不会错乱。反观 transform，要同时维护“用户滚动产生的位移”和“程序控制的位移”，一旦没理清就很容易出现跳动。

实际上，很多播放器的歌词滚动为了做缓动会直接用 requestAnimationFrame 去改 scrollTop，这也正是我下面要讲的。

3. 顺滑滚动的关键：采样策略与渲染性能

算法确定以后，剩下的问题是：多久触发一次滚动计算？监听 timeupdate 够不够？滚动动画是瞬间跳到位还是渐变缓动？

3.1 timeupdate 事件的痛点

<audio> 元素的 timeupdate 事件，规范建议的触发频率是 4~66Hz，实际操作中浏览器为了省电通常稳定在 4Hz 左右，也就是每 250ms 触发一次。250ms 对显示进度条来说够了，但歌词滚动会感觉“一格一格跳”，尤其是在句子切换的瞬间，肉眼明显看到歌词跳上去，而不是平滑滑上去。

如果想让滚动平滑得像原生 App，要么加缓动动画，要么提高采样频率。我的做法是双管齐下：

• 在主循环里用 requestAnimationFrame（每秒 60 帧）读取 audio.currentTime，保证高亮判断的实时性。
• 每次滚动位置变化时，用 scrollTop 的缓动过渡来平滑移动。

3.2 requestAnimationFrame 为主循环的取舍

很多播放器实现里，主循环代码是：

javascript复制let rafId = null;
let lastScrollTop = 0;
let currentTargetScrollTop = 0;

function tick() {
  const ct = audio.currentTime * 1000;
  const index = findCurrentLineIndex(lyrics, ct);
  if (index !== currentHighLightIndex) {
    currentHighLightIndex = index;
    updateHighLightClass(index);
  }

  const target = calculateTargetScrollTop(index);
  currentTargetScrollTop = target;
  smoothScrollTo(target);
  rafId = requestAnimationFrame(tick);
}

audio.addEventListener('play', () => {
  rafId = requestAnimationFrame(tick);
});

audio.addEventListener('pause', () => {
  cancelAnimationFrame(rafId);
});

关键点是：tick 在播放状态才允许运行，暂停或结束时取消 requestAnimationFrame，避免后台空转消耗电量。实测在桌面 Chrome 和 Android Chrome 上，60fps 的循环完全没压力，但要注意循环里尽量减少不必要的 DOM 操作，只在高亮行变化时才去操作 class，而不是每帧都重新查询元素。

3.3 缓动函数：从生硬跳变到丝滑过渡

光有 60fps 采样还不够，每秒 60 次把 scrollTop 直接赋值为目标值，效果等效于瞬间跳变。要达到平滑滚动，需要做缓动。最简单的线性缓动：

javascript复制function smoothScrollTo(target) {
  const diff = target - container.scrollTop;
  if (Math.abs(diff) < 1) return;
  container.scrollTop += diff * 0.25; // 每帧移动剩余距离的25%
}

这个做法的原理是每帧向目标靠近 25%，形成“先快后慢”的缓动效果。要注意：歌曲正常播放时，目标位置本身就在持续变化（因为 currentTime 一直在变），所以 diff 不会被单帧清零，滚动会一直跟随时间走，视觉上是连续平滑的。

实测效果：句子切换瞬间，上一句平滑滑出，下一句从中间位置浮上来，延迟约 0.2~0.3 秒，体感非常接近主流播放器。慢歌的时候这种“追目标”式的缓动特别重要，因为行与行间隔时间长，如果瞬间跳变会显得很机械。

3.4 一个容易忽视的渲染问题

前面的 sample 里只做了 scrollTop 的渐变和 class 切换，但如果歌词行的字数很多、行数很多，高频切换 class 可能导致布局抖动。这里有个小技巧：把高亮行和非高亮行的样式差异尽量定义在 opacity、transform、color 这些不触发重排的属性上，不要用 font-size、line-height、padding 这些会影响布局的属性来做高亮效果。这样浏览器能走合成器而不是走重排，帧率更稳定。

我这次项目里高亮行和非高亮行的差异是 opacity、scale 和颜色，实测在 200 行以内的歌词列表全程不掉帧。

4. 用户手动滚动与自动跟随的“打架”问题

歌词滚动做完第一版，你会发现一个体验问题：你想往回看一句歌词，手指往上滑了一下歌词列表，结果下一帧程序又强制把 scrollTop 拉回当前播放位置，你根本没法看之前的内容。这就是自动滚动和用户手动滚动的对抗。

4.1 冲突场景的完整还原

当 requestAnimationFrame 循环每秒跑 60 次时，用户的每一次滚动操作都会被程序覆盖。即使你没用 smoothScrollTo，直接赋值 scrollTop 也会把用户刚刚滚走的位置拉回来。用户想查看 20 秒前的一句歌词，结果手指刚松，画面立刻跳回当前句子，体验非常糟糕。

4.2 解决方案：用户干预后暂停自动跟随

主流播放器的做法是：检测到用户正在手动滚动（touchstart/wheel/touchmove）时，自动停止主循环里对 scrollTop 的写入，只保留高亮行的判断和更新。等用户停止滚动超过一定时间（比如 3 秒），再恢复自动滚动。

javascript复制let userInteracting = false;
let resumeTimer = null;

container.addEventListener('touchstart', onUserInteract, { passive: true });
container.addEventListener('wheel', onUserInteract, { passive: true });

function onUserInteract() {
  userInteracting = true;
  clearTimeout(resumeTimer);
  resumeTimer = setTimeout(() => {
    userInteracting = false;
  }, 3000);
}

// 在tick里
if (index !== currentHighLightIndex) {
  currentHighLightIndex = index;
  updateHighLightClass(index);
}

// 只有用户不干预时才自动滚动
if (!userInteracting) {
  const target = calculateTargetScrollTop(index);
  smoothScrollTo(target);
}

注意：用户干预暂停期间，高亮行的类还是照常更新的，只是不自动滚动。这样暂停 3 秒后，如果用户还停留在之前的位置，程序再一次接管滚动时会让它平滑滑回当前句子，体验不突兀。

4.3 交互细节：是否立刻恢复跟随

这个 3 秒的恢复时间是我对比了几个播放器之后选的。太短的话，用户手指刚离开屏幕，还没看清歌词，画面就开始拽；太长的话，如果用户只是短暂瞄一眼，不想让歌词留在错误位置等半天。3 秒比较中庸，但实际要根据产品场景调整。如果是 K 歌场景，用户视线集中在当前句，可考虑 1.5~2 秒；如果是音乐播放器场景，用户可能想仔细看某几句歌词，3~4 秒更合适。

还有一个值得做的细节：用户手动滚动后，滚动条本身可能停在任意位置，当恢复自动滚动时，如果直接 smoothScrollTo 从当前位置回目标位置，会出现一段从用户位置“飞”回目标位置的动画，这是合理的，但动画时间要控制在 0.4~0.6 秒，太长了会让人觉得卡。我直接沿用之前的缓动系数，实测视觉效果刚好。

5. 一个可直接复现的完整实现方案

把前面的解析、算法、性能、交互串起来，一个 300 行左右的完整实现就能跑起来。这里给一个核心骨架和关键配置。

5.1 项目结构和核心代码

code复制lyrics-scroll/
├── index.html
├── style.css
└── main.js

index.html 里重点是容器结构：

html复制<div id="player">
  <audio id="audio" controls src="song.mp3"></audio>
  <div id="lyrics-container">
    <!-- 歌词会被JS动态渲染到这里 -->
  </div>
</div>

style.css 里设置歌词容器的高度、溢出滚动和行高：

css复制#lyrics-container {
  height: 400px;
  overflow-y: auto;
  line-height: 40px;
  font-size: 16px;
  text-align: center;
  scrollbar-width: none; /* Firefox隐藏滚动条 */
}

#lyrics-container::-webkit-scrollbar {
  display: none; /* Chrome/Safari隐藏滚动条 */
}

.lyric-line {
  opacity: 0.4;
  transition: opacity 0.3s ease, transform 0.3s ease, color 0.3s ease;
}

.lyric-line.active {
  opacity: 1;
  transform: scale(1.08);
  color: #ffb400;
}

main.js 把解析结果渲染成 DOM 行，并在主循环里驱动滚动。为了让歌词数据能被快速索引，我把每一行歌词对应的 DOM 元素也存进了数组：

javascript复制const lyricEls = [];
lyrics.forEach((item, i) => {
  const div = document.createElement('div');
  div.className = 'lyric-line';
  div.textContent = item.text;
  lyricContainer.appendChild(div);
  lyricEls.push(div);
});

这样更新高亮时就可以直接按索引操作元素，不需要再查 querySelector。

5.2 参数配置和实测数据

一套在我测试环境里稳定运行的参数如下：

手机端和桌面端实测数据如下（Chrome 92，55 行歌词，2560x1440 桌面窗口 / iPhone 12 模拟器）：

5.3 移动端隐藏滚动条但保留滚动

歌词滚动页面在移动端通常不希望看到横竖滚动条，但又要维持可滚动区域，所以 -webkit-scrollbar { display: none; } 和 scrollbar-width: none 必须成对写。注意：隐藏滚动条后，用户仍然可以通过触摸滚动，但要确保容器没有设置 overflow: hidden，否则整个滚动就废了。overflow-y: auto 是正确的选择。

5.4 迁移到 Vue / React 的注意点

这个原生实现迁移过去时有个容易出错的地方：框架的虚拟 DOM 和高频 scrollTop 修改叠加，可能造成不必要的重新渲染。我的建议是：在 Vue 或 React 里，歌词行渲染用框架，但 tick 和 smoothScrollTo 不要走响应式数据，直接用 ref 或一个普通对象持有容器 DOM 引用，在框架外修改 scrollTop 和 class。如果你把 currentIndex 做成响应式，每次歌词切换都会触发整个列表重新渲染，性能会差很多。

6. 踩坑记录：真机测试中遇到的几个让人头疼的问题

写代码的时候觉得逻辑清晰，一到真机测试，问题全冒出来了。这里挑三个印象最深的记录一下，也是后续做同类功能最值得注意的地方。

6.1 慢歌的时候歌词逐渐偏移，问题出在浮点数累积

第一版我用的是 audio.currentTime（秒）直接和歌词时间（毫秒）比较，结果发现一首歌放到后半段，高亮歌词比实际唱到的句子慢了半句。排查发现是 currentTime 在 3 分钟时会有类似 179.9999999 的浮点误差，乘以 1000 后变成 179999.9999，在某些边界上可能比 180000 小 0.1 秒，导致该切歌的时候没切。修法很简单：Math.round(audio.currentTime * 1000) 取整毫秒再做比较，而不是直接用浮点数。

6.2 快速切歌时跳行动画闪烁

第一版在切歌时直接把新歌词数组渲染进容器，再重置 scrollTop = 0，结果看到旧歌词闪了一下新歌词才出现。原因是重置 scrollTop 发生在 DOM 更新前，浏览器绘制的还是旧内容。解决办法是：先清空容器、重置 scrollTop，再渲染新歌词，强制一次重绘。或者在渲染新歌词前先把容器的 opacity 设为 0，渲染完再过渡回 1，视觉上更干净。

javascript复制function loadNewLyrics(newLrcText) {
  lyricContainer.style.opacity = 0;
  lyricContainer.scrollTop = 0;
  lyricContainer.innerHTML = '';
  // 解析并渲染新歌词
  // ...
  requestAnimationFrame(() => {
    lyricContainer.style.opacity = 1;
  });
}

6.3 移动端 Touch 事件的 passive 警告与滚动穿透

在 Chrome 移动端调试时，控制台会警告 Added non-passive event listener to a scroll-blocking 'touchstart' event。我一开始在 touchstart 里调用 preventDefault() 来阻止默认行为，结果整个滚动被锁死，页面完全划不动。把 passive: true 加上，并移除 preventDefault() 后恢复正常。记住：监听用户是否交互只需要在 touchstart 或 wheel 里做标记，不需要阻止默认事件，否则滚动区域就废了。

6.4 循环播放时最后一句歌词悬在列表中间

循环播放时，音频从最后一句跳回第一句，如果当前 currentIndex 还停留在最后一行，而新的 currentTime 已经小于第一行歌词时间，findCurrentLineIndex 返回 -1，这时我就不应该再更新歌词滚动位置，保持默认位置为 0 即可。这个边界一开始没处理，导致循环播放时歌词停留在末尾，直到第一句歌词时间才恢复正常。加上对 index === -1 的提前返回就解决了。

最后分享两个后续可以扩展的方向

这次随手练习做完之后，我发现这个功能还有几个可以扩展的点。一个是点击歌词跳转播放位置，做法很简单：给每行歌词绑定 click 事件，拿到歌词行的 time，直接把 audio.currentTime = time / 1000 即可，滚动逻辑不用改。另一个是把高亮行做成“当前句可复制分享”，比如长按歌词行复制当前句歌词和对应时间戳，生成类似 “00:16 童年的荡秋千” 的文本，这个对社区类产品是很好的互动点。

歌词滚动的核心其实就是“时间→行→scrollTop”的映射关系，理解了这条链路，剩下都是在调体验。希望这篇能帮你少走几步弯路。