Network面板过滤Img可查实际加载图源；若只显示fallback图，说明所有source未匹配，需检查media语法、顺序及Content-Type一致性。
Network 面板里看实际加载了哪张图
浏览器不会告诉你“为什么没走 source”，只会静默 fallback 到 <img src>。调试第一步就是打开 DevTools → Network → 刷新页面，过滤 Img 类型，观察最终请求的 URL 是什么。
常见线索：
- 如果只看到
hero-fallback.jpg，说明所有<source>都没匹配上——检查media语法、断点顺序、是否漏括号 - 如果看到
hero-mobile.jpg但视口是桌面宽度，大概率是<source>顺序错了（手机规则写在最前） - 如果某张图状态是
blocked:mime-type，说明type="image/webp"和服务器返回的Content-Type不一致（比如返回了text/plain或大小写错误） - 404 不报错，但会直接跳过该
<source>，继续往下匹配；若全部 404，最终就只剩<img src>
用 matchMedia 手动验证 media 查询是否生效
浏览器对 media 的解析和 JS 中 window.matchMedia() 完全一致。把你的 media 值复制出来，直接在 Console 里运行：
matchMedia('(max-width: 768px)').matches
结果为 false？那它在 <source> 里也一定不生效。常见错误：
立即学习“前端免费学习笔记（深入）”；
-
media="max-width: 768px"→ 缺少括号，必须是media="(max-width: 768px)" -
media="(min-width: 768px) and (max-width: 1024px)"→ 检查当前视口宽度是否真落在这个区间（注意单位是 px，不是 rem/em） -
media="(orientation: landscape)"→ iOS Safari 行为不稳定，不建议用于关键路径
检查 HTML 结构是否满足硬性要求
<picture> 不是“写了就能用”的标签，三个条件缺一不可，否则整个结构被降级或留白：
-
<source>必须在<img>之前，且全部嵌套在<picture>内部；<source>放在<img>后面 = 被忽略 - 最后一个子元素**必须是
<img>**，且带src和alt；没有src，区域就是空的 - 所有
srcset和<img src>的路径必须真实存在；不存在 ≠ 报错，而是静默跳过
顺手检查：右键 → “查看网页源代码”，确认结构层级和属性拼写（比如 srset 这种低级拼写错误很常见）。
用 device toolbar 模拟不同断点并观察 DOM 变化
Chrome DevTools 的 Device Toolbar（Ctrl+Shift+M）不只是改视口尺寸，它还能触发真实的媒体查询重计算。操作时注意：
- 切换预设尺寸（如 “iPhone 12”）后，立刻看 Elements 面板里
<img>的src属性是否已更新为对应<source>的srcset中的某个值（浏览器会在匹配后把最终选中的 URL 写进<img>的src） - 手动拖拽宽度时，留意断点临界值（如 768px）——如果在 767px 和 769px 之间反复横跳却始终加载同一张图，大概率是断点重叠或间隙（比如一个用
max-width: 768px，另一个用min-width: 768px） - 开启 “Show rulers” 可直观确认当前视口宽度数值，避免靠感觉估算
真正麻烦的从来不是写错一行 HTML，而是某张裁切图少传了一个像素，或者某台测试机的系统缩放导致 DPR 计算偏移——这些细节得靠 Network + DOM + matchMedia 三路交叉验证才能揪出来。
