audio.currenttime拖动失效的典型表现是点击或拖拽后音频不跳转、滑块回弹、松手跳回原位，本质是timeupdate与input事件冲突导致逻辑覆盖；必须监听loadedmetadata获取duration，用change而非input响应拖拽，通过isuserinteracting等状态隔离js与用户控制权。

audio.currentTime 拖动失效的典型表现

点击或拖拽进度条后，音频没跳转、滑块回弹、松手瞬间跳回原位置——这不是浏览器 bug，而是事件冲突导致的逻辑覆盖。核心问题在于：timeupdate 和 input 事件同时修改 audio.currentTime，且没有状态隔离。

必须监听 loadedmetadata 才能读取 duration

audio.duration 初始为 NaN，直接赋值给 input.max 会导致控件不可拖。不等元数据加载完成就初始化进度条，等于在空跑道上发号施令。

Wechat HTML Publisher

直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。

下载

• 只在 loadedmetadata 事件中设置 progress.max = audio.duration 或降级为 100
• 避免在 canplay 或 play 事件里读 duration，它们触发时元数据未必就绪
• 移动端尤其敏感：iOS Safari 常延迟触发 loadedmetadata，可加 500ms 超时兜底

input.input 与 input.change 的关键区别

用 input 事件监听拖拽过程，会高频触发；但设 audio.currentTime 必须等到用户松手——否则拖动中被 timeupdate 反向覆盖，造成“跳帧”错觉。

• 拖拽响应应绑定 change 事件（松手才触发），而非 input
• 同步播放进度到控件时，改用 timeupdate + requestAnimationFrame 节流，避免卡顿
• 别信 progress.valueAsNumber，它在 Safari 下常四舍五入丢精度，坚持用 parseFloat(progress.value)

移动端 range 滑动不跟手的真实原因

iOS Safari 和部分安卓 WebView 对 input[type="range"] 的 touch 支持弱，不是 CSS 问题，是底层事件穿透和响应延迟。单纯加大 thumb 尺寸或 z-index 无效。

• 必须监听 touchstart + touchend，手动补全 change 事件（iOS 不触发 mouseup）
• 安卓部分机型需加 cursor: pointer 触发硬件加速，否则滑动卡顿
• 真要保体验：放弃纯 range，用 div + touchmove 自绘滑块，把 currentTime 计算权完全收归 JS

拖动兼容异常最棘手的地方不在逻辑多复杂，而在于「同一时间点上，你既想让 JS 控制进度，又想让用户控制进度」——这两者天然互斥。真正健壮的方案，永远靠状态标记（如 isUserInteracting）和事件隔离来划清边界，而不是靠加更多监听器硬扛。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！