audio进度条无法拖动的根本原因是duration为NaN或服务端不支持HTTP Range请求。需等待loadedmetadata事件后再读取duration，用change而非input事件设置currentTime，并确保服务端返回206状态码。
audio 标签默认进度条无法拖动，根本原因不是样式或按钮坏了，而是浏览器压根没拿到可拖动的必要信息——duration 是 NaN，或者服务端不支持分片加载（HTTP Range），导致 currentTime 写入后无响应。
audio.duration 为 NaN 导致拖拽失效
这是最常见、也最容易被忽略的第一道关卡。只要 audio.duration 没就绪，所有基于时间的交互（包括拖拽跳转）都会静默失败——你拖了，但音频不动，控制台也不报错。
- 必须等
loadedmetadata事件触发后才能读取duration，不能在 DOM 加载完就直接赋值input.max - 如果音频是动态设置
src（比如用户选文件），每次换源都要重新监听loadedmetadata，否则新文件的duration仍是旧值或NaN - 某些 MP3 文件缺少 ID3v2 头信息，或用老旧编码器生成，会导致 Chrome/Firefox 无法解析时长；可尝试用
ffmpeg -i in.mp3 -c copy -write_xing 0 out.mp3重写头信息
input[type="range"] 拖拽时 audio.currentTime 被 timeupdate 覆盖
你松开鼠标那一刻音频“跳回原位置”，不是 bug，是 timeupdate 和 input.input 两个事件在竞态：拖拽中 timeupdate 还在高频更新 input.value，而你刚设的 currentTime 立刻被下一次 timeupdate 触发的赋值冲掉。
- 别在
input事件里直接设currentTime，改用change事件（仅在松手后触发一次） - 同时监听
seeked事件，在它触发后再同步input.value = audio.currentTime，避免中间状态干扰 - 如果仍需拖拽过程实时预览，可用
requestAnimationFrame节流timeupdate的更新频率，例如每 60ms 最多更新一次input.value
服务端不支持 HTTP Range 请求引发 seek 卡顿
拖动进度条本质是 seek 行为，浏览器会发带 Range: bytes=xxx- 的请求。若服务端返回 200 OK 而非 206 Partial Content，浏览器只能中断连接、重下整个文件——看起来就像“拖不动”，实际是卡在加载。
立即学习“前端免费学习笔记（深入）”；
- 本地开发用
python -m http.server必定失败，必须换live-server或http-server -c-1 - Nginx 需确认响应头含
Accept-Ranges: bytes，禁用gzip_static或自定义add_header干扰 - Flask/FastAPI 静态文件服务要显式用
send_file(..., conditional=True)，否则默认不处理 Range - 跨域音频必须加
crossorigin="anonymous"，且服务端响应头要带Access-Control-Expose-Headers: Content-Range
移动端 range 输入框滑动异常
iOS Safari 和部分安卓 WebView 对 input[type="range"] 的 touch 支持薄弱，表现为滑动延迟、跳变、无法拖到末尾，甚至 touchstart 不触发。
- 不要依赖
progress.valueAsNumber，它在 iOS 上四舍五入精度丢失严重，统一用parseFloat(progress.value) - 给
input添加touch-action: manipulationCSS，减少滚动/缩放拦截 - 更稳妥的降级方案：PC 用
input[type="range"]，移动端改用div+touchstart/move/end手动计算偏移，映射到currentTime - 测试时务必真机连
quark://inspect或 Safari Web Inspector，模拟器常掩盖 touch 事件问题
真正卡住进度条的，往往不是某一行 JS 写错了，而是 metadata 加载、服务端响应、事件调度、移动端手势这四层链路里有一环断了。逐层验证比反复改样式更有效——先看 Network 面板里音频请求是否返回 206，再查控制台有没有 loadedmetadata 日志，最后才动 JS 逻辑。
