应采用“上一行缓存+时间宽容窗口”策略：缓存 lastIndex，判断条件改为 currentTime + 50 >= line.time && currentTime - 50
ontimeupdate 触发太稀疏，直接比对 currentTime 容易跳行
浏览器对 audio.ontimeupdate 的触发并不均匀，尤其在低端设备或主线程繁忙时，可能连续跳过 200–300ms。如果只写 if (currentTime >= line.time)，会漏掉中间几行，导致高亮滞后甚至“卡住”。
解决方法不是加轮询，而是用「上一行缓存 + 时间宽容窗口」：
- 记录上一次匹配的索引
lastIndex，避免每次从头遍历整个歌词数组 - 判断条件改为
currentTime + 50 >= line.time && currentTime - 50 （单位毫秒） - 仅当新索引 ≠
lastIndex时才更新 DOM，防止无谓重绘
parseLRC 解析时间戳时，毫秒位处理不一致会导致错行
LRC 时间格式如 [01:23.45]，其中 .45 是百分之一秒（即 450ms），不是毫秒。很多解析函数误把它当毫秒处理，比如 parseFloat('23.45') * 1000 → 23450ms，实际应是 23 * 1000 + 45 * 10 = 23450ms —— 这个巧合容易掩盖问题；但遇到 [01:23.05] 就暴露了：parseFloat 会截成 23.05 → 23050ms，而正确值是 23050ms？不对，是 23 * 1000 + 5 * 10 = 23050ms，看似一样，但若用 toFixed(3) 或字符串截取错误（比如没补零），就会变成 23.5 → 23500ms，偏移 450ms。
安全做法是显式拆分：
立即学习“前端免费学习笔记（深入）”；
function parseTime(str) {
const [min, sec] = str.split(':');
const [whole, centi = '00'] = sec.split('.');
return (+min * 60 + +whole) * 1000 + (centi.padEnd(2, '0').slice(0, 2) * 10);
}高亮时反复改 scrollTop 或调用 scrollIntoView 会卡顿
歌词行数一多（比如 50+ 行），每帧都调用 scrollTop = index * lineHeight 或 li.scrollIntoView()，会强制同步布局计算，移动端尤其明显。Safari 下还可能因 scroll-behavior 不兼容直接失效。
更轻量的做法是：用 transform: translateY() 移动整个歌词容器，而不是滚动它：
- 把所有
<li>包进一个固定高度的<ul class="lyrics-list"></ul> - 给
.lyrics-list设position: relative，然后 JS 动态设style.transform = `translateY(${offset}px)` -
offset=(targetIndex - centerOffset) * lineHeight，centerOffset 通常是可视区行数的一半（比如显示 5 行，就取 2）
用 background-color 高亮会触发重排，渐变背景下更卡
哪怕只是加个 .highlight { background-color: rgba(255, 255, 0, 0.3); }，在有 CSS 渐变、阴影或复杂背景的容器里，也会让浏览器放弃 GPU 加速，降级为 CPU 绘制。
替代方案更稳：
- 用
outline: 2px solid #ffcc00—— 不占布局空间，开销极低 - 或
box-shadow: 0 0 8px rgba(255, 204, 0, 0.6)—— 同样不触发重排 - 绝对避免在
.highlight里写height、padding、margin等影响盒模型的属性
关键点其实不在“怎么高亮”，而在于“怎么不让高亮拖慢播放”。DOM 操作越少、样式越薄、时间判断越容错，滚动就越跟得上音频节奏。特别是移动端，ontimeupdate 和渲染帧率不同步是常态，硬刚不如绕开。
