srcset本身不降级，仅提供多图供浏览器选择；真正兜底的是src属性，它在IE、旧WebView或断网时强制生效，且必须指向可访问的通用格式图片。
直接说结论：srcset 本身不“降级”，它只是提供多张图让浏览器选；真正起兜底作用的只有 src 属性——IE、旧 Android WebView、甚至部分断网场景下，浏览器只认这个。别指望 srcset 自动 fallback 到小图或 JPEG，它没这功能。
为什么写了 srcset 还是加载了最大图
核心不是浏览器“选错了”，而是你没给它足够准确的决策依据。浏览器结合 sizes 声明的渲染宽度 + 当前 window.devicePixelRatio + srcset 中的 w 或 x 描述符，查表匹配最接近的源。常见失效点：
-
sizes缺失或写成固定值（如sizes="100vw"），浏览器只能按视口宽估算，小屏也拉大图 -
srcset混用单位：比如"a.jpg 400w, b@2x.jpg 2x"，整条被忽略 - CSS 实际限制了图片容器宽度（如
max-width: 300px），但sizes写的是(max-width: 768px) 100vw，导致计算出的“目标尺寸”远大于实际需要 - 开发时没禁用缓存，DevTools Network 面板看到的是缓存响应，误判加载逻辑
srcset 里该用 w 还是 x
看你要适配的维度：
- 只适配高分屏（Retina、iPhone Pro）：用
x最简洁，例如srcset="icon.png 1x, icon@2x.png 2x, icon@3x.png 3x"，sizes可省略（浏览器默认按 1× 渲染宽度推算） - 既要适配不同视口宽度（移动端小图、桌面大图），又要兼顾高 DPR：必须用
w+sizes，例如srcset="photo-400w.jpg 400w, photo-800w.jpg 800w, photo-1200w.jpg 1200w"配合sizes="(max-width: 480px) 90vw, (max-width: 768px) 45vw, 33vw" -
w和x绝对不能混写在同一srcset中，Chrome/Safari 会直接丢弃整条
src 不是可选项，是强制保命线
所有不支持 srcset 的环境（IE8–11、Android 4.3 前 WebView、JS 被禁、断网）都只读 src。它必须满足三个硬条件：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
- 指向一个真实可访问的资源：不能是空字符串、
"#"、相对路径错误、或带后端参数（如logo.jpg?format=webp） - 格式通用：JPEG 或 PNG，避免 WebP/AVIF（老浏览器解码失败且不 fallback）
- 尺寸合理：建议 800w 左右主图，够清晰又不至于首屏卡顿；别用 1px GIF 当兜底（alt 文本会撑开布局）
漏掉 src 或它 404，结果就是白屏——不是“降级失败”，是降级链从根上断了。
高 DPR 下图片模糊？问题大概率不在 HTML
srcset 只管加载哪张图，不管怎么渲染。Canvas 模糊、CSS 缩放后失真、甚至 img 在 Safari 上边缘发虚，90% 是因为没同步处理设备像素比（window.devicePixelRatio）：
- Canvas 必须同时设置
canvas.width/canvas.height（物理像素）和canvas.style.width/canvas.style.height（CSS 像素） - 纯 CSS
transform: scale(2)或zoom会拉伸位图，不可逆；应优先用srcset加载高 DPR 图，再用原尺寸显示 - Safari 移动端对
@media (-webkit-min-device-pixel-ratio: 2)支持不稳定，别依赖它做 JS 图片替换
最容易被忽略的一点：sizes 声明的宽度必须和实际 CSS 布局完全一致——哪怕差 1px，浏览器计算出的目标尺寸就可能跳档。验证时别只看页面是否“显示了”，要进 DevTools Network 面板确认到底加载了哪个 URL。
