srcset本身不降级，真正起作用的是src+srcset+sizes三者协作的fallback链路；漏掉任一环，高分辨率图加载失败就会白屏。
srcset 本身不降级，它只做分辨率匹配；所谓“srcset降级”是误称，真正起作用的是 src + srcset + sizes 三者协作下的 fallback 链路——漏掉任一环，高分辨率图加载失败时就会白屏。
为什么写了 srcset 还是加载了最大图？
浏览器不是按“谁清晰选谁”，而是按 sizes 声明的渲染宽度 + 设备像素比（DPR）反推需要多大的资源。常见失效原因：
-
sizes没写，或只写了(max-width: 768px) 100vw却没覆盖桌面断点，导致 Chrome 默认 fallback 到100vw加载最大图 -
srcset里的320w描述符和图片真实宽度不符（比如图其实是 640px 宽却标成320w），计算出的目标尺寸偏差，选错源 - CSS 中对图片容器设置了
max-width或transform，但sizes的媒体查询没同步适配，造成声明与实际渲染宽度错位 - 开发时双击打开 HTML 文件（
file://协议），部分浏览器会忽略srcset直接走src
<picture></picture> 里 srcset 和 img 的关系怎么理清？
<picture></picture> 中的 srcset 属于 <source></source>，它只负责“格式/媒体条件匹配”，不解决加载失败问题。关键逻辑：
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
-
<source></source>按顺序匹配，第一个type被支持且media为真就生效，其余跳过 -
<source srcset="a.webp" type="image/webp"></source>加载失败（如 404、解码错误），不会自动切到下一个<source></source>，浏览器只报错，继续尝试渲染该<source></source>对应的资源 -
<img alt="HTML进阶srcset降级方案讲解教程" >是强制兜底，不是“备用选项”——无论<source></source>是否匹配、是否加载成功，它都会被解析并尝试加载；所以它的src必须独立可用、静态可靠 -
<img alt="HTML进阶srcset降级方案讲解教程" >必须是<picture></picture>的最后一个子元素，否则 HTML 解析异常，整组失效
如何让 srcset 真正具备容错能力？
靠纯 HTML 不行，必须叠加运行时控制。核心是把 srcset 的“分辨率选择”和“加载失败兜底”拆开处理：
立即学习“前端免费学习笔记（深入）”；
- 用
srcset+sizes做初始分辨率决策，确保首屏加载最优图 - 给
<img alt="HTML进阶srcset降级方案讲解教程" >绑定onerror，但不能只换一次：onerror="if (!this.dataset.attempted) { this.dataset.attempted = '1'; this.src = '/img/fallback.webp'; }" - fallback 图必须是 WebP/JPEG/PNG 中最兼容的一种（如 JPEG），且服务器返回的
Content-Type必须严格匹配（image/jpeg），否则仍可能解码失败 - 终极兜底建议用内联 SVG：
this.src = 'data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMTAiIGhlaWdodD0iMTAiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PC9zdmc+'，零请求、无跨域、无 MIME 校验风险
最容易被忽略的一点：所有参与 srcset 或 <source></source> 的图片，原始像素尺寸必须完全一致。哪怕只是 JPEG 清除了 EXIF 元数据，浏览器在切换时也会重排布局——这不是样式问题，是 intrinsic size 变了。
