preload="metadata"无法显示时长和进度条的根本原因是服务端缺失accept-ranges: bytes响应头，导致浏览器无法分段获取元数据，只能退化下载部分文件解析；需配合js调用.load()、监听waiting/canplay事件及audio.buffered实时计算缓冲进度。
音频缓冲慢不是代码写错了，而是加载链路上多个环节松动了——从服务端响应头、preload策略，到前端事件监听和 DOM 状态，漏掉任意一环都会让“loading”卡在视觉或逻辑层面。
为什么写了 preload="metadata" 还看不到时长、进度条不动
根本原因是服务端没返回 Accept-Ranges: bytes 响应头，浏览器无法用 HEAD 请求快速获取元数据，只能退化为下载部分文件块解析，而这个过程极易被中断或超时。
- 用
curl -I https://your.domain/audio.mp3检查响应头，确认含Accept-Ranges: bytes；Nginx 默认支持，但若开了gzip_static或自定义add_header可能覆盖它 - Flask/FastAPI 静态服务默认不支持 Range，必须用
send_file(..., conditional=True) - 本地开发别用
python -m http.server，它完全不支持 Range，换http-server -c-1或live-server - MP3 文件若无 ID3v2 尾部或 VBR 头信息，
duration会是NaN，即使preload="metadata"成功也显示不了总时长
waiting 和 canplay 事件比 loadeddata 更准
用户感知的“卡”，发生在拖动后停顿、点播放后空白、进度条跳变这些时刻，waiting/canplay 正是对这些行为的直接反馈，比网络层事件更贴近体验。
-
waiting一触发就该显示 loading（比如加audio-loadingclass），别等 fetch 完——那是网络请求完成，不是播放准备就绪 -
canplay触发后立刻隐藏 loading，哪怕还没play()；否则用户点下按钮还要多等半秒动画收起 - 用户拖进度条、切音源时会再次进入 buffering，
canplay必须重新监听，不能只绑一次 - 如果
audio.readyState （即未达 <code>HAVE_CURRENT_DATA），就算buffered.length > 0也不代表真能播，得综合判断
用 buffered 算真实缓冲进度，别只转圈
旋转动画会让用户误以为“一直在努力”，而 audio.buffered 是浏览器实际缓存区的真实快照，做成进度条式 loading，体验更透明、可预期。
- 首次
loadedmetadata后就得初始化一次，不然进度条永远为 0 - 用
audio.buffered.end(0) / audio.duration算当前缓冲比例，但要先确保audio.duration > 0，否则 fallback 到NaN - 配合
timeupdate每 200ms 更新一次，避免高频重绘；移动端可延长到 500ms 节省 CPU - 有些浏览器刚加载时
buffered.length === 0却已进入HAVE_METADATA，所以不能单靠buffered.length === 0判断“没缓”
真正预加载得靠 JS 主动调 .load()，不是靠 HTML 属性
preload 是弱提示，尤其在 iOS Safari、Chrome 省电模式、Firefox 隐私模式下常被忽略。想让音频真正在后台静默加载，必须 JS 控制时机与流程。
- 确保
audio已挂载到document.body下（display: none或position: absolute都可以），未挂载的元素调.load()会静默失败 - 先设
preload="none"，再赋值src，然后立即调.load()—— 这样能绕过浏览器对preload的降级策略 - 监听
canplaythrough（表示缓冲足够连续播放），比loadeddata更可靠；若已进loadedmetadata状态，再调.load()不会重发请求，需先清空src再重设 - 动态改
preload值（如从none改auto）不会触发重加载，必须配合.load()或重设src
最易被忽略的点是：服务端不支持 Range，前端再怎么监听事件、怎么调 .load()，seek 时照样卡顿；而前端没监听 waiting，用户点播放后看到的就只是空白，不是 loading。这两端不一起修，优化就是纸上谈兵。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
