src属性是唯一可靠兜底，必须指向真实可访问的JPG/PNG图；srcset仅提供现代浏览器候选资源，不支持时自动回退至src，二者须共存且分工明确。
srcset 本身不负责“兼容降级”，它只提供候选资源；真正兜底的是 src 属性。只要 src 指向一个真实可访问、格式广泛支持的图（如 .jpg 或 .png），老浏览器（IE、旧 Android WebView）就能显示，现代浏览器则按规则选 srcset 中最合适的——这是唯一可靠、零 JS 的降级路径。
src 和 srcset 必须同时存在且分工明确
很多人只写 srcset，结果 IE 直接不渲染图片，连 alt 都不显示。这不是 bug，是规范行为。
-
src是强制存在的兜底：必须指向一个体积适中、格式兼容性极广的图（比如 800w 的.jpg），不能是空字符串、"#"或 404 路径 -
srcset是可选增强：只在支持它的浏览器中生效，提供更细粒度的资源选择能力 - 不支持
srcset的浏览器会忽略整个属性，只加载src；支持但匹配失败时，也自动回退到src
sizes 属性写错，srcset 就等于白写
只写 srcset="a.jpg 400w, b.jpg 800w" 却漏掉 sizes，浏览器会默认按 100vw 计算渲染宽度，小屏手机也可能加载 800w 图——这不是“没降级”，是选错了。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
-
sizes必须反映图片**实际渲染宽度**，不是容器宽度，也不是“大概差不多”：比如 flex 项里占 50%，就得写sizes="(max-width: 768px) 100vw, 50vw" - 所有
srcset条目必须统一用w描述符（如photo-400.jpg 400w），混用x（如2x）会让整个srcset被浏览器静默忽略 - 检查是否生效：打开 DevTools → Network → 点开图片请求 → 看 Request Headers 里有没有
Sec-CH-DPR或Width，没有说明浏览器压根没走响应式逻辑
WebP/AVIF 不能靠 srcset 回退，必须用
试图用 srcset="photo.webp, photo.jpg" 实现格式降级？浏览器根本不认这种写法。WebP/AVIF 支持检测是 MIME 类型级的，<img alt="HTML怎么用srcset做响应式图片同时兼顾兼容降级" > 没有 type 判断能力。
立即学习“前端免费学习笔记（深入）”；
- 格式降级唯一标准方案是
<picture></picture>，且<source></source>顺序决定优先级：第一个type被支持 +media匹配成功的才会加载 -
type值必须严格匹配真实 MIME：写成image/webp，不能是webp、.webp或image/WebP - 底部的
<img src="fallback.jpg" alt="HTML怎么用srcset做响应式图片同时兼顾兼容降级" >不是“备用”，而是最终渲染载体——它必须可用，否则整个<picture></picture>在不支持浏览器里退化为空白
最容易被忽略的点：无论用 <img srcset alt="HTML怎么用srcset做响应式图片同时兼顾兼容降级" > 还是 <picture></picture>，src 或最底层 <img alt="HTML怎么用srcset做响应式图片同时兼顾兼容降级" > 的地址一旦不可达（404、CORS、路径错误），整个链就断了——用户看到的不是“模糊图”，是白屏或破损图标。别指望浏览器自动重试，也别指望 JS onerror 补救能抹平体验断层。
