audio元素刷新时必停因DOM与JS上下文被销毁，非bug而是浏览器规范；可用sessionStorage保存/恢复状态实现秒级续播，或用iframe隔离避免刷新中断。
页面刷新时 audio 元素为什么一定会停
因为刷新会销毁整个页面 DOM 和 JavaScript 执行上下文，Audio 实例、播放状态（currentTime、paused、volume）全部丢失。这不是 bug，是浏览器行为规范——没有机制让单个 HTML 页面“记住自己正在播什么”。
用 sessionStorage 保存并恢复播放状态
这是最轻量、无需改架构的补救方案，适合单页或跳转不多的场景。关键不是“防止中断”，而是“中断后秒级续播”。
-
beforeunload事件中保存：sessionStorage.setItem('bgm_time', audio.currentTime)、sessionStorage.setItem('bgm_paused', audio.paused) - 页面加载后检查：
if (sessionStorage.getItem('bgm_paused') === 'false')再调audio.play() - 必须等
loadedmetadata或canplay后再设置currentTime，否则 Safari/Chrome 会忽略 - 注意：如果音频是跨域资源且服务端没返回
Accept-Ranges: bytes，currentTime设置可能失败
iframe 隔离才是真正的“不断播”解法
如果你的项目本质是多 HTML 文件（比如 scene1.html → scene2.html），别在每个页面里放 <audio></audio>。直接放弃“单页刷新续播”思路，改用 iframe 架构。
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 主页面（
index.html）固定包含<audio id="bgm"></audio>和播放控制逻辑 - 所有游戏/内容页（
scene1.html等）不带音频，只通过<iframe src="scene1.html"></iframe>嵌入主页面 - 跳转由主页面 JS 控制：
document.getElementById('gameFrame').src = 'scene2.html'，不触发整页 reload - iframe 内需通知主页面同步状态（如暂停 BGM）时，用
parent.postMessage()通信，主页面监听message事件处理
Media Session API 不解决刷新问题，但影响后台行为
它和刷新无关，只管“页面失焦后系统是否允许继续解码音频”。如果你已经用 iframe 或单页做到了不刷新，那加这个能让锁屏界面显示播放控件、支持键盘媒体键。
立即学习“前端免费学习笔记（深入）”；
- 必须在用户有交互后（比如点击播放按钮）才能调用：
navigator.mediaSession.metadata = new MediaMetadata({ title: "BGM" }) -
navigator.mediaSession.setActionHandler('pause', () => audio.pause())这类 handler 只在页面 active 时有效 - 切到其他标签页后，
audio.play()仍可能被拒绝，错误信息是："DOMException: play() failed because the document is not visible"—— 此时只能等用户切回来再恢复
真正难的不是“怎么存时间点”，而是区分清楚：你遇到的是刷新中断（页面重载）、还是失焦中断（标签页切走）、还是跨页面中断（HTML 文件跳转）。三者成因不同，混用方案只会让问题更模糊。
