autoplay与muted必须同时显式设置在html中，缺一不可；现代浏览器（chrome 66+、firefox 66+、safari 13.1+）默认拦截有声自动播放，仅静音状态下允许生效，且ios需用户首次手势授权后才可触发播放。
autoplay + muted 组合必须同时存在，否则桌面端也播不了
现代浏览器（Chrome 66+、Firefox 66+、Safari 13.1+）已全面实施自动播放策略：有声音频的 autoplay 默认被拦截，哪怕写成 autoplay="autoplay" 或只加 autoplay 属性都无效。唯一能“静音自动播”的路径，是显式声明 muted ——注意不是 volume="0"，也不是 JS 后设 audio.volume = 0，这些都无法绕过策略。
常见错误：
- 写了 autoplay 但漏掉 muted → 桌面 Chrome/Firefox 静默失败，控制台无报错
- 用 JS 动态设 muted = true 再调 play() → 失效，必须属性在 HTML 中就存在
- 在 iOS Safari 上仅靠 autoplay muted 仍可能不播 → 因为它还要求页面已获得用户手势授权（如用户点过任意区域），这是硬性前提
移动端必须用用户手势触发首次 play()，且要处理 Promise 拒绝
iOS Safari 和 Android Chrome 对音频生命周期极其敏感：未获用户交互前，AudioContext 处于 suspended 状态，<audio></audio> 的 play() 调用会直接 rejected，不会抛异常，但 Promise 会失败。
- 所有首次
play()必须包裹在click、touchstart等用户事件回调中，不能放在load、canplay或定时器里 - 必须用
audio.play().catch(e => console.warn('play rejected:', e))捕获拒绝，否则失败无声无息 - Android Chrome 建议用
decodeAudioData()预解码而非直接 new Audio()，避免因解码延迟导致后续play()失败 - iOS 上若想后续恢复有声播放，需在用户手势后调
audioCtx.resume()（如果用了 Web Audio）或直接设audio.muted = false（但仅限已激活上下文）
标签必须带 type，MP3 写 audio/mpeg，不是 audio/mp3
省略 type 属性时，Chrome 可能碰巧加载成功，但 Safari（尤其 iOS）会跳过该 <source></source>，导致 canplay 不触发、duration 为 NaN、控制台静默失败——这不是 bug，是规范行为：浏览器只按 MIME 类型匹配，不“猜”编码。
实操要点：
- <source src="bgm.mp3" type="audio/mpeg"></source> ✅
- <source src="bgm.mp3"></source> ❌（iOS 直接忽略）
- <source src="bgm.mp3" type="audio/mp3"></source> ❌（非标准 MIME，Safari 不认）
- 视频建议双源：MP4（video/mp4）+ WebM（video/webm），音频可单 MP3，但务必补 type
preload="metadata" 是跨平台最稳的选择
preload="auto" 在 iOS 上完全被忽略，且会触发不必要的预加载，浪费流量；preload="none" 则可能导致首帧等待过长。唯一兼顾兼容与体验的是 preload="metadata"：它只拉取头信息（时长、尺寸、编码），不下载主体数据，既满足 canplay 事件触发条件，又避开 iOS 的预加载限制。
额外注意：
- 不要依赖 loadeddata 或 canplaythrough 来判断“能播了”，iOS 这些事件触发不稳定，优先监听 canplay
- 设置 currentTime 必须等 canplay 后再操作，iOS 在此之前设值无效
- 桌面端虽宽松，但统一用 preload="metadata" 可避免因格式差异导致的加载逻辑分裂
真正的难点不在写法，而在于“用户手势”这个状态不可跨页面持久化：iOS 一次点击只解锁当前上下文，切 Tab、刷新、甚至某些 PWA 场景下都会重置。这意味着你无法靠“点一次，永久有声”，每次进入新上下文都得重新唤起——这点最容易被忽略。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
