现代浏览器默认禁止无用户交互的音频自动播放，autoplay属性已退化为建议；必须在用户点击等手势回调中调用play()，且静音（muted）是实现无缝播放的关键前提。
audio 标签的 autoplay 属性为什么经常失效
现代浏览器（Chrome、Firefox、Safari、Edge）默认禁止无用户交互触发的音频自动播放，这是硬性策略，不是 bug。即使写了 autoplay，只要页面没经过用户点击、触摸或键盘操作，audio 就不会响——哪怕加了 muted 也不行（除非同时满足静音 + 页面可见 + 用户已与同源页面有过交互）。
常见错误现象：audio 元素加载完成但无声，控制台无报错，play() 调用抛出 NotAllowedError: play() failed because the user didn't interact with the document first.
- 必须在用户手势（如
click、touchstart）回调中调用play()，不能放在DOMContentLoaded或load里 -
autoplay属性本身已基本退化为“建议”，实际行为由浏览器策略主导 - 移动端尤其严格：iOS Safari 要求
muted+autoplay+ 用户首次触摸后才可能生效
muted 属性是自动播放的必要条件吗
不是“必要”，而是“解锁静音自动播放的通行证”。带声音的自动播放（即非 muted）在绝大多数桌面和移动浏览器中已被彻底禁用；但若音频本身静音，浏览器允许它随页面加载自动开始，后续再通过 JS 取消静音并恢复声音。
使用场景：视频背景音效、游戏启动音、H5 广告首帧音频等需要“无缝启动”的场合。
- 必须同时设置
muted和autoplay：<audio muted autoplay src="bg.mp3"></audio> - 静音状态下调用
play()成功后，可立刻设audio.muted = false，但部分浏览器（如 Safari）会立即暂停，需在稍后微任务中再操作：setTimeout(() => { audio.muted = false; }, 10) -
muted是布尔属性，写成muted=""或muted="muted"效果相同，推荐简写muted
如何用 JavaScript 可靠触发自动播放
最稳妥的方式是把 play() 绑定到用户第一次交互事件上，并确保音频已加载就绪。不要依赖 canplay，优先用 canplaythrough 或直接 catch 播放失败后重试。
const audio = document.querySelector('audio');
document.body.addEventListener('click', () => {
audio.play().catch(e => {
console.warn('Auto-play prevented:', e.name);
// 可选：提示用户点击按钮手动播放
});
}, { once: true });
- 务必加
{ once: true }，避免重复绑定 - 不要在
load或DOMContentLoaded中调用play()，此时用户尚未交互 - 如果音频资源较大，可在用户交互前预加载：
audio.preload = 'auto'，但不保证加载完成时间 - 某些安卓 WebView（如微信内置）需额外配置：在 X5 内核中可能需开启
webview.getSettings().setMediaPlaybackRequiresUserGesture(false)（仅限 App 侧可控环境）
loop、preload、controls 等辅助属性的实际影响
这些属性不解决自动播放权限问题，但会影响用户体验和资源加载节奏。
-
loop：纯逻辑控制，循环播放与是否自动无关；但若想“自动循环”，仍需先成功触发一次play() -
preload取值：none（不预加载）、metadata（只加载元信息）、auto（尽量加载）。设为auto可提升首次播放响应速度，但会增加初始流量 -
controls：显示原生控件。若隐藏控件（不写该属性），务必提供自定义播放按钮，否则用户无法手动补救自动播放失败的情况 -
crossorigin：当音频跨域时必须设置（如 CDN 资源），否则play()可能因 CORS 报错被拒绝
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
