仅用<picture>标签本身不省流量，必须配合srcset+sizes+CDN动态裁剪URL三者协同，才能在电商等多尺寸场景下稳定节省40%–70%图片带宽；<picture>是格式与尺寸的决策开关，不直接选图，真正选图依赖<source>中的srcset、sizes及浏览器对视口的计算。
直接结论：仅用 <picture> 标签本身不省流量，必须配合 srcset + sizes + CDN 动态裁剪 URL 三者，才能在电商、资讯等多尺寸场景下稳定节省 40%–70% 图片带宽。
为什么单独写 <picture> 没用
很多人把 <picture> 当成“高级 <img>”，只塞一个 <source> 或全用固定尺寸 URL，结果体积反而更大——因为浏览器仍会下载 fallback 的 <img src>，且没触发尺寸匹配逻辑。
关键点在于：<picture> 不是图片容器，而是「格式与尺寸的决策开关」。它不决定加载哪张图，只决定「哪些候选图可被选中」；真正选图的是内部 <source> 的 srcset 和 sizes，以及浏览器对当前视口宽度的计算。
- 错误写法：
<source src="banner.jpg">—— 缺少srcset和media，等同于无效声明 - 更糟写法：
<source srcset="banner.jpg 1200w" media="(min-width: 768px)">—— 同一 URL 带多个w描述符，浏览器可能重复请求 - 正确前提：每个
srcset条目必须是独立裁剪后的 URL，且其w值必须等于该 URL 中实际输出的宽度参数（如?w=480）
必须配齐的三个技术动作
省流量不是靠标签堆砌，而是靠三者协同生效：
立即学习“前端免费学习笔记（深入）”；
-
srcset列出真实存在的、不同宽度的 CDN 裁剪图（如https://cdn.com/p.jpg?w=480 480w, https://cdn.com/p.jpg?w=800 800w），不能是同一张图加多个描述符 -
sizes必须用具体值（如(max-width: 480px) 100vw, 50vw），禁用100%或未定义值，否则浏览器按默认 100vw 计算，大概率选错尺寸 -
<source type="image/webp">必须放在<source media>之前——浏览器从上到下匹配，遇到第一个支持且满足条件的就停；WebP 放最后会导致旧 iOS Safari 加载 JPEG 失败（因 URL 含&被截断）
移动端特别注意的兼容坑
iOS Safari 对含多个 & 的 URL 解析不稳定，老版本（<source> 加载失败后 fallback 到 <img src>，而后者若也带 CDN 参数（如 src="p.jpg?w=800"），降级时可能 404。
- 优先用路径式参数：把
https://cdn.com/p.jpg?w=480&h=270&fit=cover改成https://cdn.com/w_480,h_270,c_fill/p.jpg - 若必须用查询参数，对
&做 URL 编码：写成%26，例如?w=480%26h=270%26fit=cover -
<img src>必须是无参数的原始图（如p.jpg），确保所有不支持<source>的环境都能兜底加载 - 不要依赖
loading="lazy"在<picture>内自动生效——它只作用于<img>，且需同时存在width/height和sizes才可靠
CDN 动态裁剪 URL 是省流量的核心杠杆
真正让 <picture> 发挥价值的，不是你写了多少个 <source>，而是每个 srcset 条目背后是否由 CDN 实时生成对应尺寸的图。静态切图维护成本高、覆盖率低；CDN 裁剪能按需输出任意宽高比+格式组合。
- 验证方式：打开 Chrome DevTools → Network → 看图片请求 URL 是否含
w=、h=、fm=webp等参数，且响应头含Content-Length明显小于原图 - 典型配置示例：
<source srcset="https://cdn.com/w_480,f_webp/q_auto/p.jpg 480w, https://cdn.com/w_800,f_webp/q_auto/p.jpg 800w" type="image/webp"> - 漏掉这步，
<picture>就只剩格式降级价值（WebP → JPEG），尺寸适配能力归零
最容易被忽略的点：CDN 裁剪 URL 必须和 srcset 中的 w 描述符严格一致，差 1px 都可能导致浏览器误判。这不是语法问题，是资源寻址逻辑问题——写错一个数字，用户就得多下几百 KB。
