仅靠标签无法精确拖动或实时更新进度条，必须配合currenttime、duration和事件监听手动控制；需监听loadedmetadata后读取duration，用input事件响应拖拽，timeupdate事件同步进度，注意移动端自动播放限制和浏览器兼容性差异。
如何用原生 HTML + JavaScript 实现带进度条的音频播放控制
直接说结论：仅靠 <audio></audio> 标签无法精确拖动或实时更新进度条，必须配合 currentTime、duration 和事件监听手动控制——否则会出现拖动失效、进度跳变、NaN 值报错等问题。
为什么 input type="range" 拖动后音频不跳转
常见错误是只绑定 change 事件，漏掉 input 事件，导致拖拽过程中无响应；或未在音频加载完成（loadedmetadata）后再读取 duration，此时 duration 为 NaN，导致计算崩溃。
- 必须监听
loadedmetadata才能安全读取audio.duration - 拖动时用
input事件（非change），保证滑块实时响应 - 设置
audio.currentTime后需加try/catch，某些格式（如未分片 MP3）在未加载完时设值会抛错 -
<input type="range">的max初始应设为100，等duration可用后再动态改写为真实秒数
进度条同步更新的关键三步
核心逻辑是让进度条“动起来”：播放时持续更新 value，同时避免因频繁 DOM 操作卡顿。不要用 setInterval，优先用 timeupdate 事件。
- 监听
audio.timeupdate，而非轮询——浏览器会在音频时间变化时自动触发 - 每次触发时计算：
range.value = (audio.currentTime / audio.duration) * 100（百分比更稳定） - 若
audio.duration === Infinity（比如流式音频），改用audio.buffered.end(0)做上限参考
移动端兼容性与静音自动播放的坑
iOS Safari 和部分 Android 浏览器禁止自动播放带声音的媒体，且 currentTime 在未用户交互前设值无效——进度条可拖，但拖完不生效。
- 首次播放必须由用户手势触发（如点击按钮调用
audio.play()），之后才能自由控制currentTime - 移动端
input[type="range"]滑动可能延迟，建议加touchstart+touchmove补充监听 - 不要依赖
canplaythrough判断就启用拖动，它只表示“理论上能播完”，不代表duration已就绪；稳妥做法是等loadedmetadata+duration > 0
真正麻烦的不是写几行代码，而是不同浏览器对 audio 生命周期的处理差异——比如 Chrome 允许拖动未加载完的部分，Safari 则直接卡住。测试时务必真机验证，别只看桌面端效果。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
