浏览器按顺序检查每个source的type属性是否被支持,再验证实际编解码器兼容性,首个两者均满足的即被选用;type错误或缺失会导致跳过该source,即使文件存在。
source 切换时,浏览器到底按什么规则选?浏览器不是随机挑,也不是按顺序“第一个能播就用”,而是先检查 type 属性是否被支持,再结合 MIME 类型和文件实际可解码性做决策。如果 type 写错或缺失,哪怕文件本身存在且格式正确,Chrome、Firefox 也可能直接跳过该 source。
常见错误现象:video 黑屏无报错,DevTools 的 Network 面板里对应 source 请求根本没发出——说明浏览器压根没尝试加载它。
type 必须是标准 MIME 类型,比如 "video/mp4"、"video/webm"、"video/ogg",不能写成 "mp4" 或 "video.mp4"
type 声明了且浏览器支持该类型,仍可能尝试加载(但后续解码失败会触发 error 事件)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() 流程type 属性还有用吗?有,但作用受限。浏览器用 type 做预判,但最终是否加载,取决于响应头里的 Content-Type 是否匹配,以及能否实际解码。
典型问题:Nginx 默认不给 .webm 文件设 video/webm,导致即使你写了正确的 type,浏览器收到 text/plain 也会拒绝加载。
Content-Type
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 数量,并不能保证多端一致播放。