浏览器主动终止后台有声音频播放是策略限制；可行方案为Media Session API（系统级媒体控制）或iframe隔离（避免页面重载），Service Worker无法直接播放音频。
现代浏览器不允许网页在后台（标签页失焦、系统休眠、屏幕关闭等场景）持续播放有声音频，这是策略限制，不是 bug 或配置遗漏。所谓“后台播放”，实际只有两种可行路径：一是利用系统级媒体会话（Media Session API），让音频在标签页失焦后仍能被系统识别并控制；二是把音频逻辑抽离到独立上下文（如 <iframe> 或 Service Worker），避免页面卸载导致中断。
为什么 audio 标签在标签页切走后就停了
这不是代码写错了，是浏览器主动终止的。Chrome、Edge、Firefox 均在标签页不可见时暂停所有带声音的 <audio> 播放（静音状态除外）。即使加了 loop、autoplay、muted，只要用户切换到其他标签页或最小化窗口，播放就会被挂起。
- 触发条件包括：页面失去焦点、浏览器进入后台、系统锁屏、设备休眠
-
muted只能绕过「首次自动播放」限制，不能维持后台播放 -
play()返回 Promise 被 reject 的常见错误信息是："DOMException: play() failed because the document is not visible"
Media Session API 是唯一标准方案
它不改变播放行为本身，而是告诉操作系统：“这个页面正在播放媒体”，从而允许锁屏界面显示播放控件、支持键盘多媒体键、并在部分安卓设备上维持音频解码线程。
- 必须配合已开始播放的
<audio>实例使用，不能单独启用 - 需设置元数据：
navigator.mediaSession.metadata = new MediaMetadata({ title: "BGM", artist: "Game" }); - 必须注册事件监听器才能响应外部控制：
navigator.mediaSession.setActionHandler('play', () => audio.play()); - 仅当页面处于 active 状态时注册才有效；切到后台后 handler 不再触发，但系统 UI 仍可显示状态
iframe 隔离是跨页面连续播放的实操解法
如果你的目标是“用户点击链接跳转到新 HTML 页面时音乐不断”，那根本问题不是后台，而是页面重载销毁了 DOM。此时 <iframe> 是最轻量可靠的方案。
立即学习“前端免费学习笔记（深入）”；
- 主页面（
index.html）固定包含<audio>和播放控件，不参与跳转 - 游戏/内容页面（如
scene1.html）全部通过<iframe src="scene1.html">加载到主页面内 - 所有跳转逻辑由主页面 JS 控制：
iframe.src = "scene2.html"，不触发整页刷新 - 注意：iframe 内容无法直接调用父页面的
audio实例，需用postMessage通信
Service Worker 无法直接播放音频
有人误以为用 Service Worker 缓存音频 + 定时唤醒就能后台播，这是误区。Service Worker 没有 DOM、没有 AudioContext、也不能调用 play()——它连 <audio> 元素都看不到。
- 它只能做资源预加载、离线缓存、推送通知
- 真正播放必须发生在主页面上下文中，且需用户交互激活音频上下文
- 试图在 SW 中 new Audio() 或调用
fetch()后 decodeAudioData 会直接报错
最容易被忽略的一点：你调试时看到“后台停了”，大概率不是因为没写 Media Session，而是压根没让音频成功进入播放状态——检查 audio.readyState === 4 和 audio.play().catch() 的输出，90% 的“后台失败”其实卡在前台首次播放就静默拒绝了。
