srcset未生效主因是未配合sizes或sizes描述与实际渲染宽度不符；单独用仅支持dpr切换，需sizes告知浏览器图片占位宽度才能按视口选图。
浏览器在发起图片请求前就完成资源选择，不依赖 CSS 或 JS；带宽节省的关键在于 sizes 告诉它“这张图实际占多宽”，srcset 提供“每张图物理有多宽”，两者配合才能跳过下载大图再缩放的浪费。
为什么写了 max-width: 100% 还是加载了 2MB 大图？
因为 CSS 不参与资源选择——浏览器看到 <img src="big.jpg"> 就直接发请求，不管后面有没有 max-width。它不会等样式计算完再去换图。
-
src属性仅作 fallback，现代浏览器基本忽略它来选图 - 真正起作用的是
srcset中的w描述符 +sizes的媒体条件组合 - 如果没写
sizes，浏览器按100vw猜测渲染宽度，高 DPR 设备上容易误选过大的图
sizes 怎么写才不会在 iPhone SE 上加载 1200w 版本？
写死像素值（如 "480px"）或漏掉小屏断点，会导致浏览器在窄视口下仍按大尺寸估算。必须用 vw 或带 max-width 的媒体查询明确声明渲染宽度。
- 推荐写法：
sizes="(max-width: 480px) 100vw, (max-width: 768px) 50vw, 33vw" - 避免
"480px"：它不随 DPR 变化，在 3x 屏上会被当作 1440 CSS 像素宽，触发更大图下载 - 移动端优先，第一个条件覆盖最小视口（如
320px或375px），别留空档
<picture></picture> 里 <source></source> 的匹配顺序为什么不能乱？
浏览器从上到下解析 <source></source>，遇到第一个 media 匹配且 type 支持的就停，后续全部跳过。顺序即策略，错位会导致 WebP 被跳过、JPEG 被误加载。
- WebP 必须放在 JPEG 前面；AVIF 若启用，也得比 WebP 更靠前
- 不要混用
media和type在同一个<source></source>：比如<source media="(min-width:768px)" type="image/webp"></source>，可能因某设备支持 WebP 但不满足 media 而跳过，又因下一个<source></source>不支持 WebP 而退到<img> -
<img>必须存在，且自带src和srcset：它是语义载体，也是 IE11 / 旧 WebView 的唯一入口
生成多少个尺寸版本才算合理？
生成 10+ 个尺寸是典型反模式——存储成本线性增长，CDN 缓存碎片化，而收益趋近于零。实际只需覆盖关键渲染槽宽，通常 4–6 个足够。
- 常见组合：480w、768w、1024w、1200w、1600w（对应手机竖屏、平板横屏、桌面窄栏、中屏、大屏）
- 跳过 576w、840w 这类非整数倍中间值：浏览器会就近向上取整，480w 已能覆盖 ≤480px 渲染宽，768w 覆盖 481–768px，无需填满所有间隙
- 注意：AVIF 编码耗时高，活动期必须预生成，不能 on-demand，否则首屏延迟不可控
最易被忽略的一点是：sizes 的值必须与真实布局中图片的渲染宽度一致——哪怕只差 10vw，也可能让浏览器选错一个档位。上线前务必用 Chrome DevTools 的 “Network → Img” 面板验证实际加载的是哪张图，而不是靠猜。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
