srcset 单独无效，必须配合 src 和 sizes 才能实现响应式图片择优加载与平稳降级；src 提供高兼容兜底图，sizes 告知浏览器图片渲染宽度，缺一则退化为仅加载 src。
srcset 本身不提供“失败后切换”的降级能力，它只做“择优加载”；真正的平稳降级必须靠 src + srcset + sizes 三者协同，且 src 必须指向一个真实可用、高兼容性的兜底图。
为什么 srcset 单独写没用？
浏览器看到 srcset 但没配 sizes（尤其用了 w 描述符时），会直接忽略整个属性，退化为只加载 src。这不是 bug，是规范行为——sizes 是告诉浏览器“这张图在页面里实际占多宽”，没它，srcset 中的 400w、800w 就失去参照系。
- Chrome 可能 fallback 到
100vw加载最大图，浪费带宽 - Safari iOS 11–12 会完全跳过
srcset，只请求src - 写了
sizes="(max-width: 768px) 100vw"但容器被 CSS 限制在max-width: 600px，浏览器仍按 768px 断点算，选图错位
srcset + sizes 怎么写才真正生效？
关键不是“列一堆图”，而是让每个 w 值严格对应原图真实宽度，并让 sizes 真实反映 CSS 渲染宽度。例如：图片在移动端占满视口、桌面端固定 600px 宽：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
@@##@@
-
src必须存在，且不能是空字符串、"#"或 404 路径；推荐用已压缩的 JPG/PNG，体积控制在 50KB 以内 -
srcset所有项必须统一用w描述符（如400w），混用1x会导致整条属性被丢弃 -
sizes最后一项建议写明确值（如600px），避免旧版 Safari fallback 到100vw - 验证是否生效：打开 Chrome DevTools → Network 面板 → 刷新，看实际请求的是哪个 URL；或在 Console 执行
document.querySelector('img').currentSrc
当 WebP/AVIF 需要格式降级时，别硬塞进 srcset
srcset 只解决“同一格式下的尺寸选择”，不处理“WebP 不支持就换 JPG”这种跨格式 fallback。强行写 srcset="a.webp 400w, a.jpg 400w"，浏览器会当成两个 WebP 图处理，JPG 根本不会被识别。
- 必须改用
-
type必须是完整 MIME 类型，image/webp写成webp就失效 -
src必须可访问；漏掉或 404 就白屏 - 服务器返回的
Content-Type必须匹配type，用curl -I https://x.com/a.webp检查，Nginx 需配置types { image/webp webp; }
最容易被忽略的稳定性细节
很多“降级失败”其实和 srcset 无关，而是基础链路断了：比如 src 指向的兜底图本身被 CDN 缓存污染、防盗链拦截，或路径拼写错误；又或者图片容器没设宽高，加载瞬间撑开布局，触发 CLS 偏移，用户感知就是“闪一下再出来”。
-
src值必须静态存在于 HTML 中，不能靠 JS 动态注入（断网时 JS 不执行） - 禁止用
display: none包裹图片容器——Safari 和多数 Android WebView 会跳过该元素，后续show()也无法恢复加载 - 没设
width/height或aspect-ratio，图片加载前无占位，是布局抖动主因 - 监听
error做 JS 补救只是最后一道防线，不是降级主体；首次触发后务必设img.dataset.attempted = "true"防重入
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
