只适配DPR时应直接用<img srcset="a@1x.jpg 1x, a@2x.jpg 2x">，因<picture>中<source>的srcset内2x被忽略，DPR匹配仅发生在无sizes的<img>的srcset中。
只适配设备像素比（DPR）时，别用 <picture> —— 用 <img srcset> 更稳、更轻、更少出错。
为什么 <picture> 的 srcset 里写 2x 没用
<source> 的 srcset 中的 1x/2x 描述符被浏览器完全忽略。它只按 media 匹配后取第一个资源，不参与 DPR 判断。
- 写了
<source srcset="a@2x.jpg 2x">→ 浏览器加载a@2x.jpg，但不是因为 DPR=2，而是因为它就是该<source>的第一个可用项 - 想让 DPR=2 的设备加载
@2x图，必须把2x放在最外层<img>的srcset里，且不能带sizes -
<source>若只写srcset不带media或type，整条会被跳过，不参与选择
<picture> 真正该用在哪几个场景
它不是 <img> 的升级版，而是解决三类明确问题的工具：
-
艺术方向切换：手机竖屏用裁切特写的
hero-mobile.jpg，桌面横屏用全景hero-desktop.jpg -
格式降级：优先
type="image/avif"，不支持则试type="image/webp"，最后兜底<img src="photo.jpg"> -
深色模式适配：用
media="(prefers-color-scheme: dark)"加载专为暗色优化的图源
只要没这三类需求，硬套 <picture> 只会多一层解析开销，还容易因顺序、语法或服务端响应头不一致导致静默回退到 <img>。
立即学习“前端免费学习笔记（深入）”；
media 断点写错，<picture> 就等于没写
浏览器从上到下扫描 <source>，遇到第一个匹配的就停，后面全忽略。这不是“选最优”，是“短路匹配”。
- 错误顺序：
max-width: 768px放最前 → 所有设备都命中这条，宽屏规则永远不执行 - 正确顺序：从宽到窄，例如
min-width: 1200px→min-width: 768px→max-width: 767px - 断点重叠（如
max-width: 768px和min-width: 768px）→ 768px 宽度行为不可控，Chrome 和 Safari 表现可能不同 -
media必须是合法媒体查询：(max-width: 768px)✅，max-width: 768px❌（缺括号），768px❌（非查询语句）
验证是否真生效，别信控制台，看 Network 面板
很多配置看似正确，实际根本没触发——浏览器静默回退到 <img src> 是常态。
- 打开 Chrome DevTools → Network → 刷新页面 → 筛选
Img类型 → 找到对应图片请求 - 右键 →
Copy image src→ 粘贴进新标签页，确认 URL 是@2x.jpg还是-400w.jpg - 改 DPR：⚙️ → Sensors → Device pixel ratio → 设为 2 → 必须硬刷新（Ctrl+Shift+R），否则缓存干扰判断
- 看到
blocked:mime-type？检查服务器返回的Content-Type是否和type="image/webp"完全一致（大小写、拼写、斜杠）
真正麻烦的从来不是怎么写，而是所有条件都得同时成立：media 合法、source 在 img 前、type 与响应头对齐、sizes 存在且语法无误、图片文件真实可达且返回 200 —— 漏一个，就退回到 <img src>。
