最常见原因是浏览器按顺序匹配，遇首个满足条件即停止，后续规则被忽略；如media="(min-width: 768px)"写在"(min-width: 480px)"之前，小屏设备会错误命中宽屏规则。
为什么 <picture></picture> 的 source 不生效
最常见原因是浏览器按顺序匹配 source，遇到第一个满足条件的就停止，后续不管是否更优。比如写了 media="(min-width: 768px)" 和 media="(min-width: 480px)" 两个 <source></source>，但顺序反了——小屏设备会命中第一个宽屏规则，直接跳过更匹配的窄屏规则。
实操建议：
- 把最具体的、优先级最高的
<source></source>放在最前面（比如高 DPR + 宽度组合） - 用
DevTools → Network → Filter → img看实际加载的是哪个资源，不是看哪个<source></source>标签被写在前面 - 临时删掉部分
<source></source>，只留一个，确认它单独能否正确加载，排除语法或路径问题
如何验证 srcset 和 sizes 是否被正确解析
<picture></picture> 里常嵌套 <img> 配合 srcset/sizes，但很多人误以为只要写了就自动适配。实际上，sizes 值必须是有效的 CSS 长度或媒体条件表达式，且不能依赖 JS 运行时计算。
实操建议：
- 在 DevTools 的 Elements 面板中右键
<img>→ “Break on → attribute modifications”，然后缩放窗口，观察src属性是否动态变更（它不会变，但可确认浏览器是否选中了正确的候选资源） - 手动在 Console 中运行
document.querySelector('img').currentSrc，对比不同视口宽度下的返回值 - 避免写
sizes="100vw"后又用 CSS 给<img>设定max-width: 300px—— 浏览器按sizes计算“预期显示宽度”，和真实渲染宽度不一致会导致选错资源
调试 WebP/AVIF 回退失败的典型场景
用 <source type="image/webp"></source> 时，如果浏览器不支持 WebP（如旧版 Safari），会跳到下一个 <source></source> 或最终的 <img>。但很多人忘了：type 检查只看 MIME 类型声明，不校验文件内容；如果 WebP 文件实际损坏，浏览器仍会尝试加载并静默失败，最后 fallback 到下一项——而你可能误以为是格式不支持。
实操建议：
- 用
curl -I <webp-url></webp-url>检查响应头中Content-Type: image/webp是否存在且准确 - 把 WebP 地址单独粘贴到地址栏打开，确认能正常显示（排除 CDN 缓存了错误响应或转换失败）
- 不要省略最后一层
<img src="fallback.jpg">—— 它不是可选的，是<picture></picture>的必需子元素，缺失会导致整个结构不渲染
移动端真机调试时容易忽略的细节
桌面 Chrome 模拟器能骗过大部分 media 查询，但无法模拟 DPR 切换逻辑或原生图片解码行为。例如 iOS Safari 对 AVIF 支持始于 16.4，但模拟器默认可能用桌面内核，不触发真实限制。
实操建议：
- 用 Safari 技术预览版（macOS）或真机 Safari + Web Inspector 连接调试，查看
Network中实际请求的 URL 和响应头 - 在
<source></source>中同时用media和type双重约束，比如<source media="(min-resolution: 2dppx)" type="image/webp" srcset="..."></source>，避免高 DPR 设备加载低质量图 - 检查服务器是否对
.avif文件返回了正确的Content-Type: image/avif—— Nginx/Apache 默认不识别 AVIF，需手动添加 MIME 类型映射
真正卡住的时候，往往不是语法写错，而是浏览器已加载某个 <source></source> 并缓存了结果，但你改了后面的规则；清空 Network → Disable cache 再硬刷新，比反复检查 HTML 更快定位问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
