浏览器按顺序检查每个source的type属性是否被支持，再验证实际编解码器兼容性，首个两者均满足的即被选用；type错误或缺失会导致跳过该source，即使文件存在。
video 标签里多个 source 切换时，浏览器到底按什么规则选？
浏览器不是随机挑，也不是按顺序“第一个能播就用”，而是先检查 type 属性是否被支持，再结合 MIME 类型和文件实际可解码性做决策。如果 type 写错或缺失，哪怕文件本身存在且格式正确，Chrome、Firefox 也可能直接跳过该 source。
常见错误现象：video 黑屏无报错，DevTools 的 Network 面板里对应 source 请求根本没发出——说明浏览器压根没尝试加载它。
-
type必须是标准 MIME 类型，比如"video/mp4"、"video/webm"、"video/ogg"，不能写成"mp4"或"video.mp4" - 即使服务器返回的 Content-Type 不匹配，只要
type声明了且浏览器支持该类型，仍可能尝试加载（但后续解码失败会触发error事件） - 移动端 Safari 对
video/webm完全不识别，写了也白写；Android Chrome 则基本都支持mp4和webm
source 的 type 属性写对了，为什么还是加载了低优先级格式？
因为浏览器在 source 列表中找的是“第一个它能处理的”，而不是“质量最高”或“体积最小”的。顺序很重要，且这个“能处理”包含两层判断：MIME 类型支持 + 编解码器支持。
例如：你把 H.265 编码的 video/mp4 放在前面，但用户设备不支持 HEVC 解码，即使 type 正确，浏览器也会跳过它，继续往下找 H.264 的 mp4 或 webm。
- 推荐顺序：
webm（VP9/AV1）→mp4（H.264）→ogg（Theora），兼顾现代兼容与降级能力 - 不要依赖
media属性做格式分流（如media="(min-width: 768px)"），它只控制是否下载，不改变解码行为；且多数浏览器仍会预加载首个可用源 - 可通过
canPlayType()主动探测：video.canPlayType('video/mp4; codecs="avc1.42E01E"')返回"probably"或"maybe"，比盲写source更可靠
动态切换 source 时，必须重新调用 load() 吗？
必须。DOM 上改了 source，浏览器不会自动重载视频流——哪怕你清空 video 子节点再 append 新的 source，也得显式触发 load()，否则旧缓冲、旧状态全保留。
容易踩的坑：只改 src 属性（绕过 source），看似省事，但会丢失多格式 fallback 能力；而只换 source 不 load()，界面卡在上一个视频最后一帧，控制条时间也不更新。
- 安全做法：先
video.pause()，再替换source，然后video.load()，最后视需video.play() - 注意
load()是异步的，后续操作（如监听loadedmetadata）要绑定在事件上，不能紧跟着写 - 若切换前后都是同一视频文件（仅参数不同，如带时间戳），部分浏览器可能复用缓存，但行为不一致，建议统一走
load()流程
服务端没配对 Content-Type，type 属性还有用吗？
有，但作用受限。浏览器用 type 做预判，但最终是否加载，取决于响应头里的 Content-Type 是否匹配，以及能否实际解码。
典型问题：Nginx 默认不给 .webm 文件设 video/webm，导致即使你写了正确的 type，浏览器收到 text/plain 也会拒绝加载。
- 检查方式：打开 DevTools → Network → 点开视频请求 → 查看 Response Headers 中的
Content-Type - Nginx 配置示例：
types { video/webm webm; video/mp4 mp4; }，别漏掉include mime.types; - 开发环境用
file://协议时，所有Content-Type都是text/plain，此时type几乎失效，务必用本地 server（如python3 -m http.server）测试
实际项目里最常被忽略的，是 canPlayType() 探测和服务器 MIME 配置这两环——光靠写对 type 和堆 source 数量，并不能保证多端一致播放。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
