现代浏览器禁止真正自动播放有声背景音乐，必须静音 autoplay 启动后经用户交互解禁声音。需同时设 autoplay、muted、loop 和 playsinline，提供双格式音频，点击时同步执行 muted=false 后 play() 并捕获错误，ios/android 需额外处理循环与兼容性。
现代浏览器根本不允许“真正意义”的自动播放背景音乐——autoplay 属性在含音频的媒体上基本失效，除非音频初始静音且用户已发生交互。所谓“解除限制”，不是绕过策略，而是适配策略。
为什么 autoplay + loop 在页面一打开就失败？
Chrome、Firefox、Safari 等从 2018 年起统一执行 Autoplay Policy：未获用户手势（click/touchend）授权前，任何有声媒体调用 play() 都会抛出 DOMException: play() failed because the user didn't interact with the document first。这不是 bug，是强制设计。
-
autoplay="true"单独存在 ≈ 没写 -
preload="auto"只影响缓冲，不改变播放权限 - 即使加了
muted，iOS Safari 仍可能完全忽略autoplay，尤其在无playsinline时还会跳转全屏
怎么让背景音乐“看起来”是自动播放的？
核心思路：用静音 + 自动播放作为“启动器”，再靠用户第一次点击解禁声音。这样既满足策略，又接近体验目标。
- HTML 中必须同时设置
autoplay和muted：<audio id="bgm" autoplay muted loop><source src="music.mp3" type="audio/mpeg"></source></audio> - 务必提供
.mp3和.ogg双格式，避免某些 Android 或旧版 Safari 解码失败 - 添加
playsinline属性，防止 iOS 强制全屏（尤其嵌入 WebView 场景） - 不要隐藏
<audio></audio>元素用display:none——这会让屏幕阅读器丢失语义；改用视觉隐藏但保留可访问性的 CSS
用户点击后如何可靠地取消静音并播放？
关键不是“点一下就响”，而是确保 play() 调用发生在事件处理函数第一层同步上下文中，且不能被 Promise、setTimeout 或异步逻辑包裹。
- 绑定
click或touchend（移动端更稳妥），不要用mouseenter或scroll - 先设
audio.muted = false，再立刻调audio.play()，顺序不能反 - 必须
catch错误：audio.play().catch(e => console.warn("Unmute failed:", e))，否则控制台报错且无提示 - 如果用户点了按钮但没声音，大概率是音频文件本身含视频轨道（比如误用了 YouTube 下载的 .mp4），请确认是纯音频文件
iOS Safari 和部分 Android WebView 的特殊坑
iOS 是最严的：切 Tab、锁屏、甚至页面滚动都可能导致音频暂停且无法 JS 恢复；而某些 Android WebView 根本不支持 loop 原生行为，播完就停。
- 不要依赖
loop属性做唯一循环保障，加一层 JS fallback：audio.addEventListener('ended', () => { audio.currentTime = 0; audio.play(); }) - MP3 在 iOS 上的 loop 间隙可能达 0.2 秒，若需无缝，优先试
.ogg；或用 Web Audio API 手动 buffer 循环（但失去原生控件和音量调节） - 测试时务必真机验证，模拟器常表现异常
- 没有“后台播放”这种事——iOS 明确禁止网页音频在页面不可见时继续输出
真正的难点不在代码怎么写，而在接受「音频控制权必须交还给用户」这个前提。所有看似“自动”的方案，本质都是用静音启动 + 用户授权解禁的两段式流程。漏掉任一环节，就会卡在 silent playback 或直接报错。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
