source标签不支持sizes属性，该属性必须写在img元素上；picture+source+media才是响应式分流正解，source按顺序匹配media查询，img为强制fallback；video的media查询在iOS Safari中对DPR相关条件支持差。
source标签本身不支持sizes属性
这是最容易踩的坑：把 sizes 写在 <source> 上完全无效。浏览器只认 <img> 或 <picture> 里的 sizes，<source> 标签根本没有这个属性——W3C 规范里压根没定义它。
你看到的“<source sizes="...">”要么是误读文档，要么是混淆了 <picture> 场景下的写法。真正起作用的 sizes 必须出现在 <img> 元素上，哪怕它被包在 <picture> 里。
picture + source + media 才是响应式分流的正解
想按视口宽度、设备方向或 DPR 切图，必须用 <picture> 包裹多个 <source>，每个 <source> 通过 media 属性声明匹配条件，最后用 <img> 作兜底。
-
media值必须是合法 CSS 媒体查询，括号、空格、逻辑连接符一个都不能错：media="(max-width: 479px)"✅，media="max-width: 480px"❌ - 多个
<source>按顺序从上到下匹配，第一个满足即停，所以断点要互斥：先写小屏，再中屏，最后大屏 -
<img src>是强制存在的 fallback，不能省；它不参与媒体匹配，只在所有<source>都不命中时加载 -
<source>可以带srcset（如srcset="small-1x.jpg 1x, small-2x.jpg 2x"），但此时sizes仍只能写在<img>上
media 和 srcset/sizes 混用时的优先级陷阱
当 <picture> 里既有 <source media>，又有 <img srcset> 和 sizes，浏览器会分两层决策：
立即学习“前端免费学习笔记（深入）”；
- 第一层：用
media选中某个<source>（或跳过全部，落到<img>） - 第二层：如果落到
<img>，才用它的srcset+sizes做 DPR 或宽度匹配
这意味着：<source> 的 srcset 不受 <img> 的 sizes 影响；每个 <source> 的 srcset 如果存在，必须自带适配逻辑（比如只写 x 描述符），或者干脆不写——靠 media 已经切好了宽度，再加 srcset 容易冗余甚至冲突。
移动端 video 的 media 查询兼容性雷区
iOS Safari（尤其 15–16 版）对 <source media> 的支持很保守：
- 拒绝识别
min-resolution、device-pixel-ratio这类 DPR 相关查询 - 只认
width、height、orientation等基础条件 - 哪怕语法完全正确，也可能静默忽略整个
<source>，直接走<video src>或 fallback
实操建议：视频响应式分流优先用服务端适配（如 CDN 根据 UA 或 CH-ECT 头返回不同分辨率），前端仅用 media="(min-width: 768px)" 这类简单断点做粗粒度切换，别指望它能精准匹配 Retina iPad。
最常被忽略的一点：所有 media 查询必须真实对应 CSS 布局渲染后的视口尺寸，不是设计稿标称值，也不是 JS 获取的 window.innerWidth —— 开发者工具里看 Computed width 才是浏览器真正看到的宽度。
