浏览器按顺序使用首个可解码的<source>，非选最优而是选首个可用；iOS Safari强制首源为H.264 MP4，type必须带精确codecs参数（如video/mp4; codecs="avc1.42E01E, mp4a.40.2"），且不能与<video>的src共存。
HTML5 的 <video> 本身不决定播哪个文件，真正起作用的是它内部的 <source> 标签——浏览器按顺序尝试，用第一个能解码成功的，不是挑“画质最好”的，而是找“第一个能用的”。
格式顺序必须严格按兼容性排
顺序错了，整个备选链就断了。iOS Safari（包括所有 WebKit WebView）强制要求：首个 <source> 必须是 H.264 编码的 MP4，否则可能静音、禁自动播放，甚至抛 NotAllowedError。
- 推荐视频顺序：
MP4（H.264 + AAC）→ WebM（VP9 + Opus）→ （AV1 MP4 可选，放最后） - 音频顺序：
MP3 → WAV → Ogg（Vorbis）→ Opus（WebM） - Ogg（Theora）已基本淘汰，现代项目可省略
- 把 WebM 放第一位？Safari 直接跳过，且不触发后续尝试，视频可能卡在 loading 状态
type 属性必须带精确 codecs 参数
只写 type="video/mp4" 是无效的——浏览器无法判断编码是否支持，会白发一次请求再失败，浪费带宽、延长首帧时间，还难排查。
- H.264 MP4（iOS 兼容首选）：
type="video/mp4; codecs="avc1.42E01E, mp4a.40.2" - VP9 WebM：
type="video/webm; codecs="vp9, opus"（Safari 16.4+ 开始支持） - AV1 MP4：
type="video/mp4; codecs="av01.0.05M.08"（Chrome/Firefox 支持，Safari 16+ 才识别） - 绝对避免：
video/mpeg、mp4、video/mp4; codecs="h264"（标准写法是avc1）
结构规范与常见踩坑点
<source> 必须嵌在 <video> 内部，且不能和 <video> 自身的 src 属性共存——有 src 就直接加载那个，完全忽略所有 <source>。
立即学习“前端免费学习笔记（深入）”；
- 每个
src必须指向真实可访问的文件，路径支持相对或绝对 URL - 服务端返回的
Content-Type响应头必须和type值严格一致（如.webm返回video/webm，不是text/plain） - 别信文件后缀：一个
video.mp4可能是 AV1 编码，实际编码要用ffprobe验证 - 兜底文字不可少：所有
<source>后、</video>前加一句简明提示，比如“您的浏览器不支持视频播放”
验证是否真生效，别只看 Network 请求
Network 面板只看到一个请求 ≠ 播放成功。它只说明浏览器接受了第一个 <source>，但可能因 profile 不对（如 High Profile H.264）、关键帧缺失或响应头不匹配而静默失败。
- 打开 DevTools → Network → 找视频请求 → 检查响应头
Content-Type是否匹配你写的type - 用
ffprobe video.mp4查实际编码：codec_name=av1就不能配avc1.xxx - iOS Safari 测试务必用真机或 Simulator，Desktop Safari 行为不具代表性
- 不要用 JavaScript 动态插入
<source>，可能绕过浏览器原生探测逻辑
