响应式图片失效常因语法错误导致浏览器跳过所有资源而仅加载兜底图；必须确保media括号完整、type与服务器Content-Type严格一致、sizes含媒体条件和宽度单位且匹配真实CSS布局。

标签本身不优化带宽，它只是把选择权交给浏览器——你写对条件，浏览器才敢选；写错一个括号、type大小写不对、sizes漏掉单位，它就直接跳过所有，只加载那张图。

为什么总被忽略，只显示兜底图

这是最常发生的“假失效”：你以为切了分辨率，其实全在用 fallback。根本不是浏览器不支持，而是所有都没匹配上。

• media值缺括号：写成media="max-width: 768px"❌，必须是media="(max-width: 768px)"✅
• 多个source断点重叠：比如(max-width: 768px)和(min-width: 768px)在 768px 宽度时行为未定义；推荐用开区间：max-width: 767px → min-width: 768px → min-width: 1201px
• type与服务器返回的Content-Type不一致：写type="image/webp"，但 Nginx 返回text/plain或image/jpg（注意拼写、大小写、空格），Chrome 会标为blocked:mime-type
• 漏掉<img>，或写了但没src：页面留白，不是报错，是静默失败

按设备像素比（DPR）选图：用x描述符，别混w

<picture>不处理 DPR，真正起作用的是srcset里的x描述符（如2x）。浏览器根据window.devicePixelRatio自动选，无需 JS。

• 每个<source>或<img>的srcset里只能用x或w中的一种：写"photo@1x.jpg 1x, photo@2x.jpg 2x"✅；混写"photo-400w.jpg 400w, photo@2x.jpg 2x"❌（未定义行为，Safari 可能跳过整条）
• 3x图建议放最后：浏览器从左到右匹配，遇到第一个满足 DPR 的就停，1x在前、3x在后更稳妥
• <img>的src必须存在且可用：它是 DPR=1 时的保底，也是不支持srcset的老浏览器唯一入口

sizes属性写错，等于白配srcset

没有sizes，浏览器默认按100vw算——哪怕你的图只占 300px 宽，它也可能拉一张 1920w 的图下来，浪费带宽。

Wechat HTML Publisher

直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。

下载

• sizes必须是媒体条件 + 宽度单位组合：sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"✅；写成"100%"或"300px"❌
• sizes要真实反映 CSS 中的布局逻辑：如果你用grid-template-columns: repeat(3, 1fr)，那大屏下图宽≈33vw，不是100vw
• Network 面板里看请求：如果某张400w图根本没发请求，说明sizes算出的“显示宽度”远大于 400px，它被跳过了

WebP + JPEG双格式回退，type和路径必须严格对应

格式降级不是自动的：Chrome 支持image/avif就用它，不支持就跳过该<source>，不会尝试下一个；它不“降级”，只“跳过”。

立即学习“前端免费学习笔记（深入）”；

• 同一切口下，WebP 和 JPEG 的media断点必须完全一致，否则高 DPR 小屏可能加载 WebP，而中 DPR 小屏 fallback 到 JPEG，体验割裂
• type="image/webp"对应路径必须是.webp文件，且服务器返回头必须是Content-Type: image/webp（Nginx 示例：types { image/webp webp; }）
• 别依赖Accept头做服务端格式判断：现代 CDN（如 Cloudflare）可配置，但自建服务器若没开，type就是摆设

实际生效的关键不在标签嵌套多深，而在每条media是否合法、每个type是否和服务端响应头咬死、每个sizes是否和真实 CSS 布局对得上——差一个字符，浏览器就放弃整组。