media属性在的中完全无效。html标准明确规定其仅对中的生效，所有主流浏览器均忽略内的media属性，加载时只依据type支持性、http响应头匹配及首帧解码能力顺序选择首个可用源。
media 属性在 <video></video> 的 <source></source> 里不起作用——它不会触发格式切换，也不会阻止下载。你写 media="(max-width: 768px)"，浏览器照样可能把高清 MP4 和 WebM 全部预加载完。
为什么media对<video></video>的<source></source>完全无效
HTML 标准明确规定：media 属性只对 <picture></picture> 中的 <source></source> 生效，对 <video></video> 或 <audio></audio> 内的 <source></source> 无任何匹配逻辑。Chrome、Firefox、Safari、Edge 全部遵循该规范，不是 bug，是设计如此。
- 浏览器加载
<video></video>的<source></source>时，只看type是否支持 + HTTP 响应头是否匹配 + 首帧能否解码 -
media值哪怕语法完全正确（如media="screen and (orientation: landscape)"），也会被忽略 - 本地用
file://协议测试时，type匹配常失效，容易误判media“好像起了作用”
<video></video> 多格式 fallback 的真实匹配逻辑
浏览器按 DOM 顺序扫描每个 <source></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></source> - 强制首项为 H.264 MP4（iOS/macOS 全支持），WebM/AV1 放后面作降级 —— 这是唯一跨平台不出错的 baseline
- 如需按视口宽度切分辨率（非格式），必须 JS 获取
window.innerWidth后手动设置video.src并调用.load()，不能靠<source></source>的media
最容易被忽略的细节是：type 里的 codecs 字符串必须和 ffprobe 输出完全一致；而 media 属性哪怕写得再精准，也压根不会进入浏览器的资源选择流程。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
