ios safari强制要求首个为h.264 mp4，否则静音、禁自动播放或抛notallowederror；type必须精确匹配content-type及codecs，且浏览器按顺序选用首个可解码项。
必须把 H.264 MP4 放在第一个 <source></source>，否则 iOS Safari 会静音、禁自动播放，甚至抛 NotAllowedError；type 属性不能省略，且必须和服务器返回的 Content-Type 响应头逐字符一致。
为什么第一个 <source></source> 必须是 H.264 MP4
iOS Safari（包括所有 WebKit WebView）强制要求首个可解码的 <source></source> 是 H.264 Baseline Profile + AAC-LC 编码的 MP4。它不尝试 fallback —— 如果第一个不满足，整个 <video></video> 就被判定为“不可用”，后续 <source></source> 根本不会请求。
- 错误写法：
<source src="vid.webm" type="video/webm"></source>放首位 → Safari 真机上白屏或静音 - 正确写法：
<source src="vid-h264.mp4" type="video/mp4; codecs=" avc1.42e01e mp4a.40.2></source>必须排第一 - 导出时用 FFmpeg 加参数：
-profile:v baseline -level 3.0 -c:a aac -b:a 128k，避免 High/Main Profile 导致静默失败
type 属性必须带精确 codecs 参数
只写 type="video/mp4" 等于没写：浏览器无法提前过滤，可能发起一次无效请求，Network 面板里看到 200，但实际因编码不匹配而静默丢弃。
- H.264 + AAC：
type="video/mp4; codecs="avc1.42E01E, mp4a.40.2""（注意空格、逗号、引号位置） - VP9 + Opus：
type="video/webm; codecs="vp9, opus""（Safari 16.4+ 支持，旧版忽略） - AV1 MP4：
type="video/mp4; codecs="av01.0.05M.08""（Chrome/Firefox 支持，Safari 16+ 才识别） - 别写
type="video/mpeg"或type="audio/mp3"—— 这些不是合法 MIME 类型
结构与加载逻辑常见翻车点
浏览器不是“选最优”，而是“按顺序找第一个能解码成功的”：type 匹配 + HTTP 200 + 实际帧可解码，三者缺一不可。Network 面板只看到一个请求，不代表播得通。
-
<video></video>自身不能带src属性，否则所有<source></source>被忽略 - 本地开发用
file://协议时，type匹配逻辑完全失效 —— 必须走http://或https:// -
media属性在<video></video>的<source></source>中基本被所有浏览器忽略，别指望它做响应式切换 - 检查实际编码用
ffprobe video.mp4，看codec_name和profile，别信文件后缀
音频多格式的兼容写法
音频比视频简单，但同样依赖顺序和精确 type。MP3 是保底项，必须放首位；WAV 和 Ogg 是补充，现代浏览器基本不需要。
- MP3：
type="audio/mpeg"（不是audio/mp3），全平台支持 - WAV：
type="audio/wav"（PCM 未压缩，体积大，仅用于特定场景） - Ogg/Vorbis：
type="audio/ogg; codecs="vorbis""（Firefox 支持好，Safari 不支持） - Ogg/Opus：
type="audio/ogg; codecs="opus""或type="audio/webm; codecs="opus""（Chrome/Firefox 支持，Safari 16.4+） - 所有
<source></source>后必须加降级文字，如您的浏览器不支持音频播放
最容易被忽略的是：你看到 Network 面板里 MP4 请求成功了，不代表它真能播——得进 DevTools 的 Media 面板确认解码器是否初始化成功，或者监听 loadedmetadata 事件是否触发。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
