歌词同步需JS控制，audio标签须带controls且src有效；歌词用data-start/data-end标记毫秒值；ontimeupdate需缓存索引并加50ms宽容窗口防漏帧。
直接用 标签插入音频没问题，但歌词同步不是靠 HTML 标签自动完成的—— 标签不能触发高亮，ontimeupdate 事件也容易漏帧或错行。关键在 JS 控制逻辑和 DOM 结构设计。
audio 标签必须带 controls 且 src 路径有效
没 controls 属性，播放器就是隐形的；src 错了，控制台可能不报错但 Network 面板里状态码是 404 或 Content-Type 不对（比如 MP3 返回 text/plain）。
-
src必须是相对路径（如"./songs/track.mp3"）或合法 URL，"C:\xxx.mp3"这类本地路径在网页中无效 - 务必用
type的源 - 移动端想自动播放？只写
autoplay muted不够，首次必须由用户点击触发play()，否则 Promise 会被拒绝
歌词结构要用 data-start/data-end 而非 class 模拟时间
别用 class="t-23500" 或 id="l23500" 存时间戳，解析麻烦、易冲突、无法批量操作。正确方式是每句歌词用 包裹，并用 data-start 和 data-end 标记毫秒值。
<p data-start="23500" data-end="27800">山高水长 不如你笑一笑</p> <p data-start="27800" data-end="31200">风吹云散 忘了烦恼</p>
- 时间单位统一用毫秒（
audio.currentTime返回的就是秒，乘 1000 即可对齐） - 避免用单个
data-time，因为一句歌词常有起止区间，跨行判断更准 - LRC 解析后必须转成这种结构，别直接塞进
innerText就完事
ontimeupdate 回调里不能暴力遍历 + 直接 innerText
每次触发都 for...of 所有歌词、再改 innerText，DOM 更新卡顿，还容易跳行。真实场景下浏览器会节流该事件，尤其在低端机或 Safari 上。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 加缓存：记录上一次匹配的 DOM 元素和索引，只在跨行时更新，避免重复查
querySelector - 加宽容窗口：判断条件写成
currentTime + 50 >= start && currentTime - 50 ，防因事件延迟导致漏匹配 - 高亮别用
background-color，改用outline或box-shadow，减少重绘开销 - 滚动别每帧调
scrollIntoView，只在 index 变化时触发，并配{ block: 'center' }
移动端 Safari 的 ontimeupdate 更保守，需 requestAnimationFrame 补偿
iOS Safari 对 ontimeupdate 触发频率限制更严，有时几秒才一次，光靠它歌词会“卡住”。必须用 requestAnimationFrame 做二次校准。
- 在
ontimeupdate里设一个标志位needsUpdate = true，然后立即启动requestAnimationFrame循环 - 循环里只做一次时间比对和 DOM 更新，完事即停，避免持续占用主线程
- 若音频已暂停，记得清掉
requestAnimationFrameID，否则内存泄漏 - 别在回调里解析 LRC 或重新生成 DOM 节点，这些必须提前做完
真正卡住人的从来不是“怎么放歌”，而是时间精度、事件节流、DOM 更新策略这三块没调好。哪怕结构写对了，ontimeupdate 里多一行 console.log 都可能让高亮延迟半秒。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
