<picture>降级失败主因是HTML结构错误或兜底未生效：<img>缺失、type拼错、source全部匹配但加载失败（404/格式错/Content-Type不匹配）时不会触发回退；media需互斥全覆盖；onerror须内联且防循环；SSR需确保<img>src直访有效；旧WebView需外层备用<img>。
picture 降级失败不是浏览器“不支持”，而是结构写错了或兜底没守住——最常见原因是 <img> 缺失、type 值拼错、或所有 <source> 都加载失败却没触发 <img> 回退。
为什么 <picture> 里所有 <source> 都失败了，但页面还是白屏
浏览器不会因为 <source> 加载失败就自动切到 <img>。它只在「没有一个 <source> 满足 media 条件」时才用 <img>；如果 media 条件满足但资源 404、格式损坏、或服务器返回非 image/webp 的 Content-Type，浏览器就静默留白，不报错也不降级。
- 确保每个
<source>的type与服务端返回的Content-Type完全一致：image/webp、image/avif、image/jpeg（不是image/jpg） -
<img>的src必须是静态可直访路径，不能带查询参数（如logo.jpg?format=webp），否则旧浏览器可能返回 406 或损坏数据 - 所有
<source>的media属性必须互斥且覆盖全范围，避免漏掉断点导致无匹配项
onerror 在 <img> 上怎么写才真正生效
onerror 只对 <img> 自身的 src 失败触发，不监听 <source>。它必须内联写在 HTML 中，动态绑定在 Safari 和旧 Edge 中大概率失效。
- 必须加
this.onerror=null，否则 fallback 图也 404 会无限循环 - 推荐写法：
onerror="this.src='/fallback.jpg'; this.onerror=null;" - 更稳一点可加路径判断：
onerror="if (!this.src.includes('fallback')) this.src='/fallback.jpg'; this.onerror=null;" - 不要指望它捕获 CORS 阻塞、空
src、或服务器返回占位图（200 but not image）的情况
服务端渲染（SSR）环境下如何提前防住降级失效
SSR 输出的 HTML 是首屏唯一可信来源。JS 还没执行时，<picture> 就得能独立工作。任何依赖客户端 JS 补充的逻辑，在断网或 JS 加载失败时都会让图片变空白。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
-
<img>的src必须指向真实可访问的 JPEG/PNG，且该地址需能在浏览器地址栏直接打开并显示正常图片 - 避免用 CDN 动态转码路径（如
?x-oss-process=image/format,avif）作为<img>的src - 若 SSR 能预校验图片路径有效性，优先内联极简
data:URL 作兜底（如data:image/png;base64,iVBORw0KGgo...），绕过网络请求环节 - 所有格式图片的宽高、构图、裁剪比例必须严格一致，否则回退时视觉跳变比白屏还明显
IE 和旧 Android WebView 的特殊表现
IE 完全忽略 <picture> 标签，只渲染内部 <img> ——这反而是优势；但旧版 Android WebView（≤4.4）会解析失败并整个标签留白，连 <img> 都不渲染。
- 对必须兼容旧 WebView 的项目，别只靠
<picture>：在外部再包一层<div>，里面放一个独立的<img src="fallback.jpg">，CSS 控制仅在<picture>不可用时显示 - 不要给
<img>加srcset或sizes，它只负责兜底，不是响应式主力 - 确保
<img>有alt属性，否则旧 Safari 可能拒绝加载，且无障碍和 SEO 全挂
最容易被忽略的点是：你以为降级失败是因为 JS 没跑，其实问题出在 HTML 结构本身就不满足浏览器的 fallback 触发条件——<img> 不是“备用选项”，它是语义底线，也是最后防线，写错位置、写错 MIME、写错路径，它就彻底失效。
