页面失焦时应通过 visibilitychange 事件立即暂停 audio，而非依赖 blur 或 pagehide；切回后不自动恢复，需用户手势触发 play() 并配合 currenttime 恢复，多实例推荐 audiomanager 单例管理。

页面失去焦点时自动暂停 audio 元素

浏览器原生不支持跨标签页“冻结”音频，但可以通过 visibilitychange 事件监听页面是否被切走，主动调用 pause()。这是目前最可靠、无需额外状态同步的方案。

关键点在于：不是等用户切回再恢复，而是切走瞬间就暂停——避免背景音持续播放干扰用户，也防止 iOS Safari 在后台长时间运行被系统静音或终止。

• document.addEventListener('visibilitychange', () => { if (document.hidden) audio.pause(); }) 是最小可行代码
• 不要依赖 blur 或 pagehide：前者不触发于标签页切换（只对窗口失焦有效），后者在部分 Android 浏览器中不兼容或延迟高
• 如果音频正在加载中（readyState ），<code>pause() 无副作用，可安全调用
• 注意：该事件不会触发于 iframe 内部页面，若你用 iframe 嵌套游戏，请把监听逻辑放在主页面（index.html）里

切回标签页后要不要自动恢复播放？

一般不建议自动恢复。现代浏览器（尤其 iOS 和 Chrome）对非用户手势触发的 play() 极其敏感，大概率抛出 NotAllowedError，且无法静音绕过。

html-to-pptx-converter

使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

下载

更稳妥的做法是：仅记录暂停时的 currentTime，等用户下次点击播放按钮时再 play() 并 seekTo()。

• 保存时间点：audio.addEventListener('pause', () => savedTime = audio.currentTime)
• 恢复逻辑应绑定在用户可点击的控件上，而不是 visibilitychange 的 !document.hidden 分支里
• 若必须“无缝续播”，需配合首次播放上下文激活（如预加载静音文件），但复杂度陡增，多数场景得不偿失

多个 audio 元素怎么统一控制？

别用 querySelectorAll('audio') 每次遍历——容易漏掉动态插入的、或未挂载到 DOM 的实例。推荐用单例管理 + 显式注册。

• 创建一个全局 AudioManager 对象，暴露 register(audioEl) 和 pauseAll() 方法
• 每个 audio 创建后立即 AudioManager.register(audio)，避免手动维护 NodeList
• visibilitychange 中只调 AudioManager.pauseAll()，内部做空值与状态检查
• 避免对已 paused 的元素重复调 pause()，虽无害但浪费调用栈

iOS Safari 下切页暂停后，再切回点播放仍失败？

这不是 bug，是策略限制：iOS 要求「每个 audio 实例」都必须由用户手势直接触发过至少一次 play()，之后才能再次调用。切页暂停后，这个“上下文”并未丢失，但若你用的是新 new Audio() 实例，它就没有历史手势授权。

• 复用同一个 Audio 实例（而非每次新建），是解决该问题的前提
• 首次播放务必用真实用户点击（不能是 setTimeout 模拟，也不能绑在非 button/div[role="button"] 上）
• 若音频源变更（如换曲），不要 src = newUrl; play()，而应先 pause()，再 load()，最后 play() —— 否则部分旧版 Safari 会拒绝
• 错误捕获不能省：audio.play().catch(e => console.warn('play failed:', e.name))，NotAllowedError 出现时，提示用户“请再点一次播放”比静默失败更友好

真正麻烦的不是暂停本身，而是恢复时机和权限上下文的连续性。很多开发者卡在“为什么切回来点不动”，其实问题不在 visibilitychange，而在 audio 实例生命周期没管住。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！