LRC歌词解析需用正则提取时间戳并统一转为毫秒整数，存为{time,text}对象数组；ontimeupdate同步须用findLastIndex+50ms容错+索引缓存+requestAnimationFrame校准；DOM更新应采用transform位移、outline高亮和DocumentFragment批量插入。
ontimeupdate 事件本身不能直接驱动歌词同步，必须配合时间戳解析、缓存策略和 DOM 更新节流——否则滚动卡顿、高亮错行、移动端失步是常态。
怎么解析 LRC 歌词并转成可用的时间数组
LRC 文件本质是带时间标签的纯文本，格式如 [00:30.88]可否也在感叹。直接用正则提取比手写状态机更稳，关键要统一转成毫秒整数，避免浮点误差累积。
- 用
/\[(\d{2}):(\d{2})\.(\d{2,3})\]/g匹配时间部分，minutes * 60000 + seconds * 1000 + (ms || 0)算毫秒值 - 注意：LRC 中毫秒可能是两位（
.07）或三位（.070），统一补零再截取前三位，避免parseInt("07", 10) === 7这类隐式转换陷阱 - 每行歌词只取第一个有效时间戳；若一行含多个
[xx:xx.xx]（常见于翻译/注释），跳过后续，防止数据错位 - 结果存为对象数组：
[{ time: 30880, text: "可否也在感叹" }, ...]，别用嵌套数组（如[[30880, "可否也在感叹"]]），后期查找索引时类型校验成本高
为什么 ontimeupdate 直接查数组总不准
浏览器对 ontimeupdate 的触发不保证帧率，尤其在后台标签页、低端安卓机或 JS 主线程繁忙时，可能 200ms 才触发一次，而歌词行间隔常小于 300ms——直接 findIndex(line => currentTime >= line.time) 容易跨行漏判。
- 改用
findLastIndex（或手写倒序遍历）：找最后一个time ≤ currentTime的项，比正向找“首个 ≥”更抗跳帧 - 加 ±50ms 宽容窗口：
currentTime - 50 = line.time，覆盖解码延迟与事件抖动 - 缓存上一次匹配的索引，仅当新索引 ≠ 缓存值时才更新 DOM，避免重复操作
- Safari 移动端尤其保守，建议在
ontimeupdate回调里加requestAnimationFrame二次校准，但仅用于最终渲染，别放耗时逻辑
DOM 更新怎么做才不卡
歌词行数超过 20 行后，频繁 scrollTop 或 scrollIntoView 会强制同步重排，视觉明显跳变。
立即学习“前端免费学习笔记（深入）”；
- 用
transform: translateY()移动整个歌词容器，而不是滚动父容器——GPU 加速且不触发重排 - 高亮样式优先用
outline或box-shadow，避免改background-color（尤其渐变背景）引发重绘 - 所有歌词元素一次性用
document.createDocumentFragment()批量插入，别用循环innerHTML +=或逐个appendChild - 如果歌词需居中显示当前行，计算偏移量公式为：
-(currentIndex * lineHeight) + containerHeight / 2 - lineHeight / 2，lineHeight 必须用getComputedStyle实测，别硬编码
真正难的不是解析时间或监听事件，而是把音频时间流、JS 执行时机、浏览器渲染管线这三层节奏对齐——少一个节流、漏一次缓存、多一次重排，用户就会觉得“慢半拍”。
