HTML音频不播主因是格式fallback错误：必须用<source src="a.mp3" type="audio/mpeg"><source src="a.ogg" type="audio/ogg">双格式兜底，type不可写错，且需配对服务器MIME类型与用户手势触发play()。
HTML 音频在浏览器中不播，90% 不是代码写错了，而是没按浏览器解码能力+加载策略来组织 <source> 和响应头。
为什么只写 src 属性就大概率失败
浏览器不会“猜”你给的 MP3 文件是否能解码——它只看 type 值匹配 MIME 类型。省略 type 时，Chrome 可能碰巧加载成功，但 Safari（尤其 iOS）会直接跳过该 <source>，导致无源可播、canplay 不触发、duration 为 NaN。
-
<audio src="a.mp3">→ iOS Safari 静默失败，控制台无报错 -
<source src="a.mp3">（漏type）→ Firefox/Edge 可能发起多个 404 请求，直到超时 - 正确写法必须带
type：<source src="a.mp3" type="audio/mpeg">，不是audio/mp3
多格式 fallback 的顺序和取舍
不是越多越好，而是要按浏览器实际支持能力排序，且避开已知缺陷编码。
- MP3 放第一位：
type="audio/mpeg"，兼容性最广（Chrome、Safari、Edge），但注意避免 VBR 编码（Firefox 可能卡住） - OGG 放第二位：
type="audio/ogg"，仅限 Vorbis 编码（用ffprobe a.ogg确认），Firefox/Chrome 稳定，Safari 完全不支持 - WAV 放最后：
type="audio/wav"，体积大、加载慢，仅作短提示音兜底；别用 IEEE Float 编码（Chrome 直接拒） - OPUS 可选：
type="audio/opus"，Chrome/Firefox 已支持，体积比 MP3 小 30%～50%，但 Safari 仍不支持
服务器 MIME 类型配置错误是硬伤
即使 <source> 写得再全，如果响应头里 Content-Type 是 text/plain 或为空，浏览器就当普通文本扔掉，连解码器都不调用。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- Apache 用户：在
.htaccess或虚拟主机配置中加AddType audio/mpeg .mp3、AddType audio/ogg .ogg - Nginx 用户：在
types块里补audio/mpeg mp3;、audio/ogg ogg; - 本地开发别双击 HTML：用
python3 -m http.server 8000启服务，file://协议下 Chrome/Firefox 会屏蔽音频加载 - 验证方式：打开 Network 面板，确认音频请求返回 200，且 Response Headers 中
Content-Type准确对应后缀和编码
autoplay 失效不是 bug，是策略强制拦截
现代浏览器（Chrome ≥70、Firefox ≥66、Safari ≥12.1）默认阻止有声自动播放。写了 autoplay 却没声音？不是 JS 写错了，是浏览器在等用户“动手”。
- 静音自动播可行：
<audio autoplay muted>，但需确保volume === 0且未被后续 JS 改写 - 有声自动播不可行：必须由用户手势触发，例如按钮点击后调
audio.play().catch(e => {}) - iOS Safari 更严：元素必须在视口内、未被
display: none或opacity: 0遮挡，否则即使点过也静音 - 别在
DOMContentLoaded或window.onload里调play()，100% 失败
真正落地的兼容方案，从来不是靠 JS 动态判断格式，而是靠静态 <source> 顺序 + 服务端 MIME 配置 + 用户交互时机控制。最容易被忽略的是：Network 面板里那个不起眼的 Content-Type 响应头，它决定了浏览器连解码器都懒得启动。
