srcset + sizes 能省移动端带宽，因为浏览器在 html 解析阶段就根据 sizes 声明的渲染宽度和设备 dpr 计算所需物理像素，从 srcset 中精准选择最匹配的图片资源；缺失或写错 sizes 会导致默认按 100vw 加载大图，造成带宽浪费。
为什么 srcset + sizes 能省移动端带宽
因为浏览器在 HTML 解析阶段就决定加载哪张图，而不是等 CSS 渲染完再缩放——没配 sizes 时，它根本不知道图在手机上只占 320px 宽，大概率拉一张 1200w 的图回来再缩成小图显示。
实测数据：Google 案例中，正确配置后移动端平均节省带宽 42%，关键在于让浏览器选对「物理像素需求」：所需宽度 × 设备 DPR。比如 iPhone 14（DPR=2）在 375px 宽视口下，sizes="(max-width: 480px) 100vw" 算出需约 750px 物理宽，浏览器就会避开 400w 图、优先选 800w 或 1200w 候选。
- 仅写
srcset不写sizes→ 浏览器忽略srcset，退化为只加载src -
sizes写错单位（如50而非50vw）→ 整个sizes被丢弃，响应式失效 - 没设
<meta name="viewport" content="width=device-width">→ 某些 Android 浏览器算不准vw，导致选图偏差
移动端典型 sizes 配置怎么写
别套桌面端逻辑。移动端重点不是“多栏布局”，而是“全屏横幅”“卡片流”“窄列图文”三类常见场景，sizes 必须匹配真实渲染宽度。
- 全屏 banner：
sizes="(max-width: 480px) 100vw, (max-width: 768px) 100vw, 1200px"（小屏占满，大屏固定宽） - 卡片式列表（每行1张）：
sizes="(max-width: 480px) 100vw, (max-width: 768px) 50vw, 33vw"（小屏单列、中屏双列、大屏三列） - 图文混排（图宽占容器 60%）：
sizes="(max-width: 480px) 100vw, 60vw"（移动端强制撑满，桌面端按比例）
注意：sizes 最后一项不能带媒体条件，它是默认 fallback；逗号后必须空格，(max-width:480px)100vw 这种写法会直接失效。
srcset 候选图宽度怎么定才不浪费
候选图宽度不是拍脑袋定的，得覆盖「设备视口 × DPR」的常见组合。比如你 sizes 声明了 33vw，那在 1920px 宽桌面屏（DPR=1）下需约 634px，在 iPhone Pro Max（DPR=3）下需约 1900px——所以 1200w 图在高 DPR 设备上仍可能模糊。
- 推荐梯度：
400w（低端安卓）、800w（主流手机）、1200w（高端手机+中屏）、1600w（桌面 Retina） - 别用 1024w 这种“刚好适配 iPad”的值——它在 DPR=2 的 iPad 上需要 2048px，而你没提供，浏览器只能将就用 1200w
- 所有候选图 URL 必须可访问且尺寸准确；
fakeimg.pl/800x533这类服务返回的图若实际宽 ≠ 声明的800w，会导致选图失准
在线运行环境（CodePen/JSFiddle）里容易踩的坑
这类沙箱默认不注入 <meta name="viewport">，也不保证绝对路径可用，导致 sizes 计算失真、图片 404。
- 必须手动加：
<meta name="viewport" content="width=device-width, initial-scale=1">，否则vw单位在部分模拟器里无效 - 图片 URL 用绝对路径（
https://...），别用相对路径（./img.jpg）——沙箱里根路径不明确 - 别依赖 JS 检测 DPR 后动态改
src：HTML 解析阶段图片请求已发出，JS 改晚了 - 验证是否生效：打开 DevTools → Network → 切到手机模拟模式，刷新页面，看加载的是哪个
srcset中的 URL
真正起作用的永远是 sizes 告诉浏览器“这张图要占多宽”，而不是 CSS 里写的 width: 100%——后者只影响渲染，不影响加载决策。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
