靠单个<audio>标签+autoplay属性无法全终端兼容，必须组合格式兜底、MIME响应头、用户手势触发及播放时机控制四层方案。
直接说结论：靠单个 <audio> 标签 + autoplay 属性，不可能全终端兼容。必须组合格式兜底、MIME 响应头、用户手势触发、以及播放时机控制这四层才可能“响起来”。
为什么写了 <audio autoplay> 在 iOS Safari 里完全没反应
不是代码写错了，是浏览器压根不执行。iOS Safari（含微信 iOS WebView）要求两个条件同时满足才能播放：① 用户已发生真实交互（如 touchstart、click），② 元素在视口内且未被 display: none 或 opacity: 0 遮挡。只写 autoplay muted 不够——它仍需先“被点过”。Chrome 和 Firefox 桌面版对 muted 更宽松，但 iOS 是最严的卡点。
- 不要在
DOMContentLoaded或mounted钩子中调play()，100% 被拒 - 首次播放必须由用户事件同步触发，不能包在
setTimeout或 Promise.then 里 - 可先用一个空
new Audio()在按钮点击时.play().catch(() => {})唤醒媒体上下文，后续 BGM 才能自由播
<source> 的 type 写错等于没写
浏览器不会猜你 MP3 文件是不是 MPEG 编码，它只按 type 值匹配 MIME 类型。写成 type="audio/mp3" 或漏掉 type，Safari 和旧 Edge 就直接跳过该源，最终无可用音源——连错误都不报，静默失败。
- MP3 必须写
type="audio/mpeg"，不是audio/mp3 - OGG 必须用 Vorbis 编码（
ffprobe a.ogg看输出含Audio: vorbis），写type="audio/ogg" - 别加 WAV 作 fallback：Chrome 对 IEEE Float 编码的 WAV 直接拒绝
- 服务器响应头
Content-Type必须和type严格一致，否则浏览器当文本扔掉
本地开发时 file:// 协议下音频加载被静默屏蔽
双击 HTML 文件打开，或用 VS Code Live Server 以外的非 HTTP 服务，Chrome/Firefox 会直接阻止音频加载——连 Network 面板都看不到请求。这不是路径问题，是协议限制。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 本地开发务必用 HTTP 服务：Python 用户运行
python3 -m http.server 8000，Node 用户用serve或http-server - 检查 Network 面板中音频请求的响应头，确认
Content-Type是audio/mpeg或audio/ogg - Safari 还额外要求跨域音频响应头含
Access-Control-Allow-Origin: *，否则拒绝解码（连错误都不抛）
多页跳转时背景音乐中断，iframe 是目前最稳解法
每个 HTML 页面 reload 一次，<audio> 就重置一次。用 localStorage 同步时间点 + 状态，调试难、易丢、且无法解决解码中断问题。真正可行的是结构分离。
- 主页面（
index.html）只放<audio>和控制逻辑，其他游戏页（scene1.html、scene2.html）用<iframe src="scene1.html">嵌入 - 音频元素生命周期绑定在主页面，iframe 切换不触发 reload，BGM 自然不断
- 父子通信用
postMessage控制播放/暂停/音量，避免 DOM 跨域访问限制
最常被忽略的点是：你以为问题出在 HTML 写法，其实卡点往往在服务器 MIME 配置或用户交互时机。Safari 和微信 iOS WebView 的限制比文档写的更硬，别信“理论上支持”，要实测 canplaythrough 是否触发、duration 是否可读、play() 的 Promise 是否 resolve。
