srcset本身不提供降级，仅提供分辨率候选资源；真正降级依赖浏览器根据sizes、设备DPR选择后失败时回退至src指向的高兼容兜底图（如JPG/PNG），且src必须真实可用。
srcset 本身不管理图片，也不设立降级；它只提供候选资源列表，真正的降级由浏览器根据 sizes + 设备能力 + src 兜底共同完成。想“统一降级”，必须把 src 指向一个高可用、全尺寸兼容的 fallback 图，而不是指望 srcset 自动 fallback。
srcset 不是 fallback 列表，而是分辨率候选列表
很多人误以为写 srcset="a-400w.jpg 400w, a-800w.jpg 800w, a-1200w.jpg 1200w" 就等于“自动选小图失败就换大图”，其实完全相反：浏览器会按 sizes 计算出渲染宽度，再结合设备像素比（dpr），**主动选择最接近且不小于该宽度的候选项**——比如渲染宽度是 375px、dpr=2，它大概率选 800w，而非先试 400w 再失败重试。
- srcset 中任何一项加载失败（404、CORS、网络中断），浏览器不会尝试下一个，也不会退到其他 srcset 项
- 它只会退到
src属性指向的图——这是唯一真正生效的降级入口 - 若
src是空、"#"或 404 路径，结果就是白屏或破损图标 - 所有 srcset 项必须用统一描述符：
w就全用w，混用x（如2x）会导致整组被忽略
sizes 必须反映真实渲染宽度，否则 srcset 形同虚设
只写 srcset 不配 sizes，浏览器默认按 100vw 估算，高概率加载 1200w 图给手机用——流量翻倍、首屏延迟、LCP 崩溃。这不是“降级失效”，是 sizes 没告诉浏览器“这张图实际占多宽”。
- 常见正确写法：
sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw" - 错误写法：
sizes="100vw"（固定值）、sizes="500px"（像素单位不被支持）、sizes=""（空值） - 容器用了
flex或grid？sizes 得按实际布局逻辑写，不能抄模板。例如三列网格在桌面端占 33vw，就不能硬写 50vw - 开发阶段验证：用 DevTools 切 iPhone 12（3x）和普通笔记本（1x），看 Network 面板加载的 URL 是否随 DPR 变化；不变说明 sizes 或 srcset 配置没生效
海量图片的统一降级，靠的是 src + 构建层约定，不是 srcset
面对成百上千张商品图、头像、Banner，你无法为每张图手写不同 fallback。统一降级的关键，在于让所有 src 指向同一个高可用兜底路径，并通过构建工具/CDN 确保该路径永远返回可用图（哪怕只是 1px GIF 或 LQIP 占位图）。
- 推荐
src值：/static/fallback.jpg（绝对路径，避免相对路径错位）、data:image/gif;base64,R0lGODdhAQABAPAAAP8AAAAAACwAAAAAAQABAAACAkQBADs=（内联 1px GIF，零请求） - 禁止
src值："#"、""、"placeholder.png"（相对路径易 404）、"logo.jpg?format=webp"（带参数地址在旧浏览器中可能被后端拒绝） - 构建时可自动化：用 Webpack/Vite 插件扫描所有
src，或把缺失src的图自动替换为 fallback - CDN 层兜底：配置 404 重定向到 /static/fallback.jpg，确保即使原图路径失效，
src仍能返回可用内容
srcset 和 picture 不能混用降级逻辑
有人试图把 srcset 套在一起，比如在 srcset，再给内部 srcset，结果发现 fallback 行为混乱。这是因为两套机制职责完全不同：
-
-
srcset解决分辨率降级（400w → 800w → 1200w），依赖sizes和 dpr 计算 - 二者叠加时，
srcset控制该格式下的多尺寸选择；而最终src才是所有浏览器（包括 IE）的终极 fallback 入口 - 错误做法：
最容易被忽略的点：所有 fallback 图（无论是 src 还是 aspect-ratio，否则加载瞬间撑开容器，导致 CLS 崩溃。这和降级是否成功无关，但直接影响用户是否感知到“页面卡顿”或“文字跳动”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
