audio标签只写一个src不会崩溃但等同崩溃：ios safari静默跳过、firefox拒绝解码、chrome可能卡顿且duration为nan；必须用显式声明至少mp3+ogg双格式，type精确为audio/mpeg和audio/ogg，且服务器content-type须严格匹配。
audio 标签只写一个 src 就会崩溃吗
不会直接“崩溃”，但效果等同于崩溃：iOS Safari 静默跳过、Firefox 拒绝解码、Chrome 可能播一半卡住且 duration 为 NaN。浏览器不报错，只沉默——这是最危险的兼容性失败。
根本原因不是格式本身冲突，而是浏览器无法在无 type 声明时安全推断编码。比如 src="a.mp3" 不等于 type="audio/mpeg"，Safari 会直接忽略该源，连请求都不发。
- 必须用
<source></source>显式声明至少两组格式+type -
type值必须精确：audio/mpeg（不是audio/mp3），audio/ogg（不是audio/ogv） - 服务器返回的
Content-Type响应头必须与type完全一致，否则 Chrome/Firefox 会拒绝加载
MP3 和 OGG 的 type 写错会怎样
写错 type 是高频翻车点。比如把 type="audio/mp3" 当成合法值，结果所有 Safari 用户听不到声音——它根本不匹配任何已知 MIME 类型，直接跳过该 <source></source>。
更隐蔽的问题是 OGG 编码混用：audio/ogg 仅保证 Vorbis 解码器可用；若文件实际是 Opus 编码（常见于 FFmpeg 新版默认），Firefox 可能加载成功但无声，canplay 事件触发后 play() 报 DOMException: Unable to decode audio data。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 验证 OGG 编码：用
ffprobe a.ogg确认输出含Audio: vorbis - MP3 避免 VBR（可变比特率）编码，旧版 Safari 和 Android WebView 解码不稳定
- 不要加
.wav作 fallback：Chrome 对 IEEE Float WAV 直接拒绝，Firefox 虽支持但体积大、首帧延迟高
为什么顺序影响 iOS 播放成功率
iOS Safari 不支持 audio/ogg，但它仍会按顺序发起每个 <source></source> 的 HTTP 请求。如果 OGG 放前面，它先发一次 404 或超时，再试 MP3——这不仅拖慢首播，还可能触发 iOS 的资源加载节流，导致后续 play() 被静默丢弃。
正确顺序是把兼容性最强的放最前：audio/mpeg（MP3）→ audio/ogg（Vorbis）→ （可选）audio/wav（仅短提示音）。浏览器从上到下匹配第一个 canPlayType() 返回非 "" 的源，不试探、不回退。
- 别信
canPlayType()返回"probably"：它只是推测，iOS 上常误判 - 动态插入
<source></source>无效：iOS 要求所有<source></source>在audio标签首次解析时就存在 - 本地开发用
file://协议？Chrome 直接禁用play()，必须起本地服务（如python3 -m http.server）
autoplay muted 失效的三个隐藏条件
autoplay muted 看似万能，但在 iOS 上常静默失败。真正生效需同时满足：
-
muted必须是布尔属性，不带值（<audio autoplay muted></audio>✅，<audio autoplay muted="true"></audio>❌） - 页面必须已获得用户手势授权（用户至少点过一次任意区域，哪怕空白处）
-
volume不能被 JS 后续修改：哪怕只设一次audio.volume = 0，iOS 也会撤销自动播放权限
最容易被忽略的是第三点：很多自定义播放器在初始化时统一设 volume = 0，结果把 muted 的上下文给污染了。静音自动播的唯一安全路径，是靠原生 muted 属性 + 用户首次交互前不碰 volume。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
