现代浏览器默认阻止有声自动播放，需同时设 autoplay 和 muted 才能静音自动播放；iOS Safari 要求用户手势后才能恢复有声；source 顺序与 type 必须严格匹配解码能力；preload="metadata" 最稳妥；JS 播放须捕获 Promise 拒绝并监听 error 事件；服务端 MIME 类型与 Range 支持不可或缺。
现代浏览器（Chrome 66+、Firefox 66+、Safari 13.1+）默认阻止有声自动播放，仅静音状态下允许 autoplay 生效；不写 source 或顺序/类型错误，iOS Safari 和部分 Android WebView 会直接跳过音频加载，导致 duration 为 NaN、控制台静默失败。
必须同时设置 autoplay 和 muted 才能静音自动播放
单独写 autoplay 或 autoplay="autoplay" 都无效；volume="0" 或 JS 设置 audio.volume = 0 也无法绕过策略。iOS Safari 还额外要求：用户至少触发一次手势（如点击任意区域）后，后续的 play() 才可能恢复有声——这是硬性限制，无法用代码规避。
- 正确写法：
<audio autoplay muted controls></audio> - 错误写法：
<audio autoplay volume="0"></audio>或<audio autoplay></audio> - JS 中恢复声音需先设
audio.muted = false，再调audio.play()（仍需在用户手势上下文中）
<source> 的顺序和 type 必须严格匹配浏览器解码能力
浏览器按 DOM 顺序逐个调用 canPlayType()，返回 "probably" 就立刻加载，不再往后看。Safari 不认 audio/ogg，但支持 audio/ogg; codecs=opus；Chrome 优先识别 Opus；Android Hybrid WebView（如华为/联想）只读第一个 <source>。
- 推荐顺序：
<source src="a.opus" type="audio/ogg; codecs=opus">→<source src="a.m4a" type="audio/mp4; codecs=aac">→<source src="a.mp3" type="audio/mpeg"> - 必须显式写
type，不能只靠文件后缀；type="audio/mp3"是错的，应为type="audio/mpeg" - 服务端响应头
Content-Type必须与type完全一致，否则 Safari 直接拒绝解码（连错误都不抛）
preload 设为 "metadata" 是最稳妥的默认值
preload="auto" 在移动弱网下会强制下载完整音频，拖慢首屏；iOS Safari 会忽略它，部分 Android WebView 直接降级为 "metadata"；而 preload="none" 会导致首次点击播放明显延迟，且与 autoplay 冲突时可能被拒绝播放。
立即学习“前端免费学习笔记（深入）”；
-
preload="metadata"：只取时长、采样率等元数据，足够渲染controls时间轴，不占带宽 - 仅当资源 ≤200KB、CDN 加速到位、且明确需要“秒开”（如语音播报），才考虑
preload="auto" - 别在
autoplay场景下误设preload="none"
JS 播放必须捕获 Promise 拒绝并监听 error 事件
用户点击后调用 play() 不等于一定能响——NotAllowedError（策略拦截）、NotSupportedError（格式不支持）、AbortError（网络中断）都可能抛出；canplay 事件太早，音频体可能还没到；error 事件才能暴露具体哪个 <source> 失败。
- 必须用
audio.play().catch(e => { ... })包裹所有play()调用 - 监听
error：当audio.error?.code === 4，表示所有<source>均不可用 - 不要依赖
canplay判断就绪，canplaythrough更可靠但延迟高；iOS 上建议等canplay后再设currentTime，Android 可直接设后调play()
最容易被忽略的是服务端配置：Nginx/Apache 必须显式声明 add_type audio/ogg .opus 等 MIME 类型，开启 Range 请求支持，并配好 Access-Control-Allow-Origin；否则前端写得再规范，Safari 也会静默失败。
