<source>的type属性仅为提示而非强制约束，浏览器按顺序尝试加载，仅当HTTP 200、MIME匹配且可解码时才停止；若MIME不匹配或解码失败（如HEVC MP4在旧Safari），则静默卡住不fallback，需确保服务器返回正确Content-Type并优先放置H.264+AAC MP4。
video 标签本身不识别 type 属性的格式校验
浏览器不会根据 <source> 的 type 属性主动跳过不支持的格式——它只是按顺序尝试加载，直到第一个能解析的 src。也就是说，type 不是“约束”，而是“提示”，且这个提示只影响预加载和 MIME 类型匹配，不阻止加载失败后继续试下一个。
常见错误是写成这样：
<video> <source src="video.webm" type="video/webm"> <source src="video.mp4" type="video/mp4"> </video>
看起来合理，但若 Web 服务器没正确返回 video/webm 的 MIME 类型（比如返回了 application/octet-stream），哪怕浏览器支持 WebM，也会加载失败并卡住，不自动 fallback 到 MP4。
- 务必确认 Web 服务器对每种格式返回正确的
Content-Type响应头（video/webm、video/mp4、video/ogg） -
type属性不能省略，否则浏览器可能跳过 MIME 检查直接请求，反而更难诊断问题 - 不要依赖
type做“格式兜底逻辑”，它只是辅助，真正 fallback 由浏览器内部加载机制决定
多个 source 的加载顺序和失败行为
浏览器按 <source> 出现顺序依次发起请求，只要某个 src 返回 HTTP 200 + 正确 MIME 类型 + 可解析的媒体数据，就停止后续尝试；一旦某条请求失败（404、500、CORS、MIME 不匹配、解码失败），立即尝试下一条。
立即学习“前端免费学习笔记（深入）”；
容易被忽略的是：解码失败（比如 MP4 文件用 HEVC 编码但浏览器不支持）不会触发 error 事件，也不会 fallback，而是静默卡在 loading 状态或显示黑屏。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 用
canPlayType()主动探测支持性比纯靠<source>更可靠（尤其做动态加载时） - 把最兼容的格式（通常是 H.264+AAC 的 MP4）放在最后，避免低版本浏览器因前面格式失败而无响应
- 不要把不同编码的同格式文件混放（例如两个
video/mp4，但一个是 AV1，一个是 H.264），浏览器不会“选一个能解的”，只会按顺序加载第一个
如何验证 fallback 是否生效
最直接的方式是打开 DevTools → Network 面板，刷新页面，观察 <source> 对应的请求是否被发出、状态码、响应头里的 Content-Type，以及是否出现后续请求。
如果只看到第一个 src 请求，且状态是 200 但视频不播放，大概率是编码不兼容或容器损坏；如果第一个请求失败（404/403/CORS），且立刻出现第二个 src 请求，则 fallback 正常工作。
- 手动禁用某种格式支持来测试：Chrome 中访问
chrome://flags/#enable-av1-decoder关闭 AV1，再加载含 AV1 WebM 的页面，看是否 fallback 到 MP4 - 用
video.error监听失败（注意：仅对网络/解析错误有效，解码失败通常不触发） - 服务端日志比前端 JS 更可信——确认每个
src路径实际被请求过
MP4 不是万能 fallback，H.264 编码必须明确
写 type="video/mp4" 并不等于“所有 MP4 都能播”。MP4 是容器，关键在里面的视频编码（H.264 / HEVC / AV1）和音频编码（AAC / MP3 / Opus）。Safari 13+ 才支持 HEVC MP4，旧版 iOS Safari 完全不支持。
所以真正安全的 fallback 组合是：
<video> <source src="video.webm" type="video/webm"> <!-- VP9 + Opus --> <source src="video.mp4" type="video/mp4"> <!-- H.264 + AAC --> </video>
- 生成 MP4 时指定编码：
ffmpeg -i in.mov -c:v libx264 -c:a aac out.mp4 - 避免用 QuickTime 默认导出的 HEVC MP4，除非明确只面向新设备
- WebM 文件也需注意：Chrome 支持 VP9，Firefox 支持 VP8/VP9，但 Safari 直到 17.4 才开始实验性支持 VP9 —— 所以纯 WebM 在 Safari 上大概率 fallback 失败
真正起作用的不是标签嵌套结构，而是服务器响应头、编码兼容性、以及浏览器对失败请求的重试机制。漏掉任意一环，<source> 就只是摆设。
