srcset 无资源缺失降级能力，404时静默跳过不触发onerror；唯一可靠兜底是有效的img src属性配合onerror处理。
srcset 本身不提供“资源缺失降级”能力，浏览器遇到 srcset 中某张图 404，会静默跳过它，继续尝试列表中下一个匹配项——但若全部 404 或无匹配项，它不会 fallback 到 <img src alt="HTML怎么避免srcset资源缺失时页面不触发降级" >，除非你根本没写 srcset。真正兜底的永远只有 src 属性。
为什么 srcset 里图片 404 了，页面还是白屏
常见错觉是“写了 srcset 就有降级”，其实不是：srcset 只控制“选哪张图加载”，不控制“加载失败怎么办”。浏览器按 sizes + 设备 DPR 算出目标尺寸后，从 srcset 列表里挑最接近的项发起请求；该请求返回 404、超时或 CORS 拦截，onerror 不会触发（因为错误发生在 <source></source> 或 srcset 内部，而非 <img src alt="HTML怎么避免srcset资源缺失时页面不触发降级" >），最终结果就是这张图留空。
-
srcset中任意一项 404，浏览器不会报错，也不会自动切到其他项或src—— 它只按规则选一个发起请求，失败即终止 -
<img src="fallback.jpg" alt="HTML怎么避免srcset资源缺失时页面不触发降级" >是唯一能被onerror捕获的入口，srcset和<source></source>的失败完全绕过该机制 - 如果你把
src也设成占位图（如1px.gif），但没配onerror，那 404 后就真只剩那个 1px 小点，视觉上等于白屏
怎么让 srcset 缺失时还能 fallback 到可用图
核心思路：不依赖 srcset 自身容错，而是确保 <img src alt="HTML怎么避免srcset资源缺失时页面不触发降级" > 这条链路完整、可捕获、可干预。
- 必须保留有效的
src属性，且指向一个真实可访问的图（如 CDN 上的 800w JPG），不能是空值、"#"、相对路径错误地址或动态接口 - 内联写
onerror：例如onerror="this.src='/img/standard.jpg'; this.onerror=null;"—— 注意this.onerror=null必须写，否则第二次失败会无限循环 - 如果想进一步降级到 SVG 占位，把
src改成内联 data URL：src="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='100' height='100'%3E%3Crect width='100' height='100' fill='%23eee'/%3E%3C/svg%3E"，无网络请求，绝对可靠 - 避免在
srcset中混用描述符：400w和2x不能共存，否则整个srcset被浏览器忽略，退化为只读src
如何验证 srcset 是否真在起作用，而不是假降级
别只看 DevTools 的 Network 面板是否发了请求，要确认它加载的是你预期的那张图，并且失败时行为可控。
立即学习“前端免费学习笔记（深入）”；
- 在 Chrome DevTools 的 Network 面板勾选
Disable cache，刷新后观察实际加载的图片文件名和响应尺寸（右键 →Copy→Copy response查看） - 手动把
srcset中某张图的 URL 改成 404 地址（如加个错别字），再刷新，看页面是否仍显示src指向的图 —— 如果没显示，说明onerror没生效或src本身不可用 - 检查
sizes值是否匹配真实渲染宽度：比如容器 CSS 设了max-width: 600px，但sizes="(max-width: 768px) 100vw"，浏览器仍会按 768px 断点算，可能选中 1200w 图并失败 - 用
curl -I或 Postman 检查srcset中每个 URL 的 HTTP 状态码和Content-Type，AVIF/WebP 必须返回精确的image/avif或image/webp，否则静默失效
最容易被忽略的一点：服务端配置比 HTML 更关键。哪怕你把 srcset 写得再完美，CDN 返回了 404 或错误的 Content-Type，浏览器连 onerror 都不会触发——它压根不认为那是“图片加载失败”，而是“格式不识别”，直接跳过。所以排查必须从网络层开始，而不是只盯着 HTML 结构改来改去。
