用html+css+javascript实现音频播放控制需监听timeupdate等事件更新ui，动态设置range最大值，正则解析lrc时间戳，ios需用户手势触发play()且timeupdate频率受限。
怎么用 HTML + CSS + JavaScript 实现基础播放控制逻辑
纯 HTML 的 <audio></audio> 标签能播，但没法自定义按钮、进度条或实时响应播放状态。必须靠 JavaScript 绑定事件并操作 DOM。
关键点在于监听 timeupdate 事件来驱动进度条和歌词滚动，同时用 play、pause、loadedmetadata 等事件处理状态切换和初始化。
-
audio.currentTime控制/读取当前播放秒数（可写可读） - 设置
audio.volume = 0.8比直接写volume="0.8"更可靠，后者在部分浏览器中不生效 - 首次加载音频时，
duration可能为NaN，务必等loadedmetadata触发后再读取 - 不要在
timeupdate里频繁调用audio.duration.toFixed(2)—— 这会触发重排，卡顿明显
歌词同步的核心：时间戳解析与 DOM 定位
歌词文件（如 LRC）本质是带时间标记的文本，不是 JSON。同步难点不在“怎么显示”，而在“怎么把 [01:23.45] 转成毫秒并匹配当前播放时间”。
常见错误是用 String.split('[') 粗暴切分，结果遇到歌词含方括号（比如“[副歌]”）就崩了。正确做法是用正则逐行提取时间块：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
const timeRegex = /\[(\d{2}):(\d{2})\.(\d{2})\]/g;
let matches;
while ((matches = timeRegex.exec(line)) !== null) {
const totalMs = (parseInt(matches[1]) * 60 + parseInt(matches[2])) * 1000 + parseInt(matches[3]) * 10;
}
- 每行可能含多个时间戳（如重复段落），需循环匹配
- 毫秒精度按 LRC 习惯取两位小数，对应
xx.xx→ ×10 计算（不是 ×100） - DOM 同步不用 JS 动画库，用
element.scrollTop或classList.toggle()切换高亮更轻量 - 避免在
timeupdate中反复querySelectorAll('.lyric-line')—— 提前缓存节点数组
为什么 <input type="range"> 拖动后播放跳转不准
根本原因是没处理拖动结束后的“松手即跳”逻辑。原生 range 输入框只触发 input 事件（拖动中），但用户松手那一刻才是真实意图，应监听 change 事件再赋值 audio.currentTime。
- 仅监听
input会导致边拖边跳，音频解码跟不上，听起来卡顿甚至倒退 -
audio.currentTime赋值后不会立即生效，需加audio.play()（如果已暂停）否则静音 - range 的
max值必须动态设为audio.duration || 0，且要在loadedmetadata后更新，否则拖动范围为空 - 移动端 touch 事件下，
change不触发，得补监听touchend并手动触发change
兼容性雷区：iOS Safari 和部分安卓 WebView 的硬限制
iOS Safari 禁止自动播放音频（包括 audio.play() 在非用户手势内调用），且 timeupdate 频率被锁死在约 250ms 一次 —— 这意味着歌词高亮会有明显延迟，无法做到毫秒级精准。
- 不能依赖
autoplay属性，必须由用户点击按钮触发play() - 歌词滚动若用
requestAnimationFrame补帧，在 iOS 上无效，老老实实用timeupdate就行 - 部分安卓 WebView（如微信内置）不支持
audio.buffered，导致进度条缓冲区显示为空白 - 字体抗锯齿在移动端易发虚，给歌词容器加
text-rendering: optimizeLegibility有改善
歌词时间轴对齐这事，浏览器本身就不保证亚秒级精度。别在 timeupdate 里做复杂计算，也别指望 LRC 时间戳能和音频帧完全咬合 —— 差个 200ms 是常态。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
