autoplay 失效是因浏览器主动拦截，自2017年起Chrome≥66、Firefox≥66、Safari≥11要求用户手势触发有声播放；静音自动播放（muted+autoplay）最可行但iOS需首次touchstart激活，且交互后须监听loadedmetadata并用try...catch调用play()。
autoplay 属性在 Chrome/Firefox/Safari 中为什么基本失效
不是写法错，是浏览器主动拦截。自 2017 年起，Chrome ≥66、Firefox ≥66、Safari ≥11 全面执行自动播放策略：只要音频有声（muted 为 false），且未发生用户手势（click/touchstart/keydown），play() 就会被拒绝，控制台报 DOMException: play() failed because the user didn't interact with the document first。静态写 autoplay 属性等同于直接调用 play()，一样被拦。
静音自动播放（muted + autoplay）的实操边界
这是最轻量、兼容性最好的绕过方式，但有明确限制：
-
muted必须显式写出：<audio muted autoplay>✅；仅设volume="0"或 JS 动态设audio.volume = 0❌ - 桌面端 Chrome/Firefox 基本支持；Safari 14+ 支持；Android WebView 多数支持
- iOS Safari 和微信 iOS WebView 是例外：即使
muted，首次仍需用户 touchstart 才能激活——得监听一次touchstart再调play() - 静音后用户可手动点控件取消静音，此时音量恢复，但播放状态不受影响
用户交互后调用 play() 的可靠时机与写法
不能“一触即播”，必须配合资源加载状态，否则容易失败：
- 优先监听
loadedmetadata事件，而非load或DOMContentLoaded—— 否则currentTime、duration读不到，play()可能静默失败 - 务必用
try...catch包裹：audio.play().catch(e => console.warn('play blocked:', e)) - 移动端建议同时监听
click和touchstart，避免 iOS Safari 对 click 延迟响应 - 微信 Android WebView 允许首次点击后连续
play()；但微信 iOS WebView 要求每个新音频元素都得单独“激活”——即对每个audio元素，在首次交互时都执行一次play().then(() => pause())
多页跳转或单页应用中保持背景音乐不中断
原生 audio 标签无法跨页面存活，reload 或路由切换就会重置。没有“后台播放”这种事：
立即学习“前端免费学习笔记（深入）”；
- 不要依赖
localStorage存时间点再 seek —— 音频未加载完成时currentTime设值无效，且不同设备解码延迟差异大，极易断帧 - 真正可行的是：把
audio元素挂载在长期存活的容器里（如 SPA 的根节点、iframe、或 Service Worker + Web Audio API 合成的轻量音源） - 若必须用多个页面，推荐用顶层 iframe 加载音频实例，主页面通过
postMessage控制；或改用 Web Audio API 构建可复用的AudioContext实例（注意 iOS 上AudioContext仍需首次 touch 激活）
最易被忽略的一点：iOS 微信和 Safari 不认“已交互”状态的传递——哪怕你在一个页面点过按钮，跳到下个页面，音频依然要重新激活。别指望一次交互全局生效。
