音频切出后切回自动播放失效，是因浏览器强制暂停后台音频且仅允许用户交互后恢复；正确做法是切出时pause、切回时在click中play，并确保元素已加载完成。
标签页切换时插入音频，本质不是“插入”，而是监听 visibilitychange 事件后控制已有 audio 元素的播放/暂停——直接在切出时 new Audio() 或 innerHTML 插入新 audio 标签，几乎必然失败或被静音。
为什么 audio.play() 在标签页切出后再切回就失效？
Chrome、Edge、Firefox 等现代浏览器对后台标签页实施严格的媒体策略：一旦页面失去可见性（visibilityState === "hidden"），所有正在播放的音频会被强制暂停，且后续调用 play() 会抛出 DOMException: The play() request was interrupted。这不是 bug，是主动限制。
常见错误现象包括：
- 用户切走再切回，音频卡在暂停状态，UI 按钮仍显示“播放中”
- 监听
visibilitychange后立刻audio.play()，但 Promise 被 reject，控制台报错却无提示 - 用
setTimeout延迟 100ms 再 play，依然失败——浏览器不认“延迟补偿”
正确做法：切出时 pause，切回时在用户交互后 resume
浏览器只允许在用户显式操作（click/touchstart）后的 microtask 中恢复有声播放。所以不能靠自动触发，必须留一个可点击的入口。
实操建议：
- 监听
document.addEventListener('visibilitychange', ...)，切出时调用audio.pause() - 切回时（
visibilityState === "visible"），不立即play()，而是启用一个“恢复按钮”或高亮播放控件 - 该按钮的 click 回调中调用
audio.play()，并.catch(e => console.warn("resume failed:", e)) - 如果音频本就静音（
audio.muted = true），切回后可直接play()，但用户大概率需要手动取消静音才能听到
想实现“切回自动续播”？必须绕过有声限制
纯前端无法绕过策略，但可接受折中方案：
- 切出前保存
audio.currentTime，切回后用audio.currentTime = savedTime快速定位，等用户点一次再播 - 若业务允许无声启动，设
audio.muted = true+autoplay，切回后 JS 立即audio.muted = false—— 但 Safari 通常拒绝该操作，仅 Chrome/Firefox 有机会成功 - 放弃“自动”，改用
notification.permission === "granted"发桌面通知，引导用户点击通知打开页面并触发播放
容易被忽略的兼容细节
真正上线时，这几个点常被跳过导致线上静音：
-
audio元素必须已加载完成（监听canplaythrough而非loadeddata），否则切回后play()会因未就绪而失败 - iOS Safari 对 background audio 限制最严：即使页面在前台，只要 tab 切换过、或锁屏，AudioContext 可能被 suspend，需额外调用
audioContext.resume() - 不要依赖
document.hidden判断，它已被废弃，统一用document.visibilityState - 若使用 Web Audio API（如 Howler.js），切回后需检查
audioContext.state是否为"suspended"，是则必须由用户手势唤醒
标签页切换本身不触发音频能力解锁，用户手指没动，浏览器就不会给声音。这点比路径写错、格式不支持更隐蔽，也更难调试。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
