真正的目标是让音频中断不可感知、恢复无感；需用visibilitychange监听切页暂停，切回后由用户手势触发resume并跳转至暂停时刻，多页场景应将音频脱离页面生命周期。
做不到——浏览器策略强制中断有声音频的后台播放，任何“不中断”都是错觉或变通方案。真正的目标不是阻止中断，而是让中断不可感知、恢复无感。
visibilitychange 是唯一可靠监听时机
页面切走瞬间必须暂停 audio，否则 iOS Safari 会在几秒后静音，Chrome 会直接终止解码；blur 不触发于标签页切换，pagehide 在部分 Android 浏览器中延迟高甚至不触发。
- 监听
document.addEventListener('visibilitychange', () => { if (document.hidden) audio.pause(); })是最小可行代码 -
audio.pause()对readyState < 2（尚未加载完成）的实例安全无副作用，可放心调用 - 该事件不会穿透到
<iframe>内部，若你用 iframe 嵌套游戏，监听逻辑必须写在顶层index.html中
切回后不能自动 resume，必须用户手势触发
现代浏览器（尤其 iOS 和 Chrome）对非用户手势触发的 play() 一律拒绝，抛出 NotAllowedError，且无法用 muted 绕过。
- 暂停时记录时间点：
audio.addEventListener('pause', () => savedTime = audio.currentTime) - 恢复逻辑只能绑定在用户可点击的控件上，例如按钮的
click事件 - 恢复时先
audio.currentTime = savedTime，再audio.play()；注意 iOS 上若AudioContext未激活，仍可能失败
多页面跳转时音频重置的根本解法是脱离页面生命周期
每次 location.href 或刷新都会销毁整个 DOM，audio 元素及其状态必然丢失。试图用 localStorage 存时间点再 seek 是典型误区：音频未加载完成时设 currentTime 无效，不同设备解码延迟差异大，极易断帧或跳秒。
立即学习“前端免费学习笔记（深入）”；
- 真正可行的是把
<audio>实例挂载在长期存活的容器里：SPA 的根节点、独立<iframe>、或 Service Worker + Web Audio API 合成的轻量音源 - 多 HTML 文件游戏推荐用顶层
<iframe>加载游戏内容，音频控件保留在主页面中，通过postMessage控制播放/暂停/seek - Web Audio API 方案虽灵活，但需注意 iOS 上
AudioContext仍需首次 touch 激活，不能绕过用户交互门槛
最常被忽略的一点：所谓“无缝续播”，本质是控制感知而非技术上阻止中断。重点不在“不停”，而在“停得干净、恢复得自然”。多数项目卡在这里，是因为试图对抗浏览器策略，而不是顺应它设计状态流转。
