浏览器仅在无<source>满足media条件时才使用<img>，若media匹配但资源404、Content-Type不匹配或格式损坏，则静默留白；<img>必须为最后一个子元素且src可访问，type值须与服务器返回的Content-Type完全一致。
为什么里所有都失败了，但页面还是白屏
浏览器不会因为 <source> 加载失败就自动切到 <img>。它只在「没有一个 <source> 满足 media 条件」时才用 <img>；如果 media 条件满足但资源 404、格式损坏、或服务器返回非 image/webp 的 Content-Type，浏览器就静默留白，不报错也不降级。
常见现象：
- Network 面板看到
a.webp返回 404 或 500，但页面没 fallback 到<img src="fallback.jpg"> - 控制台无错误，
<picture>区域完全空白，连alt都不显示 - 用 curl 或浏览器地址栏直接访问
a.webp，发现返回的是 HTML（如 Nginx 404 页面）或空响应
根本原因：降级逻辑被绕过，不是浏览器“不支持”，而是结构失效。
如何验证 <picture> 结构是否合规
打开 DevTools → Elements 面板，逐项检查以下硬性条件：
立即学习“前端免费学习笔记（深入）”；
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
<img>必须是<picture>的**最后一个子元素**，且src属性**不能为空、不能是"#"、不能带查询参数**（如logo.jpg?format=webp） - 每个
<source>的type值必须与服务端实际返回的Content-Type完全一致：image/avif、image/webp、image/jpeg（不是image/jpg） - 所有
<source>的media属性必须互斥且覆盖全范围，例如：media="(min-width: 1200px)"→media="(min-width: 768px) and (max-width: 1199px)"→media="(max-width: 767px)" - 检查 Network 面板中每个
<source>对应请求的响应头，确认Content-Type字段存在且值正确（Nginx 需配置types { image/webp webp; }）
onerror 不触发？先看它是不是内联写的
onerror 只对 <img> 自身的 src 失败触发，不监听 <source>；它必须内联写在 HTML 中，动态绑定在 Safari 和旧 Edge 中大概率失效。
- ✅ 正确写法：
onerror="this.src='/fallback.jpg'; this.onerror=null;" - ❌ 错误写法：
onerror="fallback()"（函数未定义则整个事件处理器解析失败） - ❌ 错误写法：
img.addEventListener('error', ...)（不冒泡，无法捕获） - ⚠️ 注意：
onerror对空src、CORS 阻塞、服务器返回 200 占位图等情况完全静默——它只管“发了请求但失败”
若 fallback 图也 404，不加 this.onerror=null 会导致无限循环或静默失败。
SSR 环境下怎么确认降级真能跑通
服务端渲染输出的 HTML 是首屏唯一可信来源。JS 还没执行时，<picture> 就得能独立工作。
- 禁用 JS 后直接刷新页面，观察关键 banner 是否正常加载；若白屏，说明
<img src>路径不可用或<picture>结构缺失 - 把生成的 HTML 文件本地双击打开（
file://协议），测试相对路径是否解析正确（推荐统一用/assets/logo.jpg这类绝对路径） - SSR 输出的
<img src>必须指向真实可访问的 JPEG/PNG，且该地址需能在浏览器地址栏直接打开并显示正常图片 - 更稳做法：SSR 预校验图片路径有效性后，内联极简
data:image/png;base64,...作兜底，彻底绕过网络请求环节
最容易被忽略的是：所有格式图片的宽高、构图、裁剪比例必须严格一致。否则回退时视觉跳变比白屏还明显。
