HTML的source标签media属性怎么针对不同屏幕加载不同格式视频

在前端开发内容学习中，HTML的source标签media属性怎么针对不同屏幕加载不同格式视频是常见主题。很多人在阅读时会遇到概念分散、步骤不清和注意点难以归纳的问题。本文按照基础概念、操作流程和关键细节，对相关内容进行整理。

media属性在<video>的<source>中完全无效。HTML标准明确规定其仅对<picture>中的<source>生效，所有主流浏览器均忽略<video>内<source>的media属性，加载时只依据type支持性、HTTP响应头匹配及首帧解码能力顺序选择首个可用源。

media 属性在 <video> 的 <source> 里不起作用——它不会触发格式切换，也不会阻止下载。你写 media="(max-width: 768px)"，浏览器照样可能把高清 MP4 和 WebM 全部预加载完。

为什么media对<video>的<source>完全无效

HTML 标准明确规定：media 属性只对 <picture> 中的 <source> 生效，对 <video> 或 <audio> 内的 <source> 无任何匹配逻辑。Chrome、Firefox、Safari、Edge 全部遵循该规范，不是 bug，是设计如此。

• 浏览器加载 <video> 的 <source> 时，只看 type 是否支持 + HTTP 响应头是否匹配 + 首帧能否解码
• media 值哪怕语法完全正确（如 media="screen and (orientation: landscape)"），也会被忽略
• 本地用 file:// 协议测试时，type 匹配常失效，容易误判 media “好像起了作用”

<video> 多格式 fallback 的真实匹配逻辑

浏览器按 DOM 顺序扫描每个 <source>，一旦遇到第一个 type 被支持、HTTP 返回 200、且首帧可解码的项，就立即加载并停止后续尝试。失败则直接报错（如 iOS 上 WebM 排第一 → 静音或 NotAllowedError）。

• type 必须精确：比如 video/mp4; codecs="avc1.42E01E, mp4a.40.2"，空格、引号、逗号位置错一位，iOS 就拒绝解码
• 服务器返回的 Content-Type 响应头必须和 type 属性逐字符一致，否则即使文件存在也判定不匹配
• 不要依赖“多个 source 并列 = 自动适配”，实际是“第一个能播的才播”，其余根本不会进解码器

真正能实现屏幕/设备适配的可行方案

靠 HTML 原生 media 不行，但有稳定落地路径：

• 服务端根据 User-Agent 或 Accept 请求头，直接返回不同顺序的 HTML —— 给 iOS 设备返回 mp4 在前的版本
• 前端 JS 检测：video.canPlayType("video/mp4; codecs=...") 或 MediaSource.isTypeSupported("video/mp4; codecs=...")，再动态插入对应 <source>
• 强制首项为 H.264 MP4（iOS/macOS 全支持），WebM/AV1 放后面作降级 —— 这是唯一跨平台不出错的 baseline
• 如需按视口宽度切分辨率（非格式），必须 JS 获取 window.innerWidth 后手动设置 video.src 并调用 .load()，不能靠 <source> 的 media

最容易被忽略的细节是：type 里的 codecs 字符串必须和 ffprobe 输出完全一致；而 media 属性哪怕写得再精准，也压根不会进入浏览器的资源选择流程。