浏览器加载最大尺寸图片，根本原因是sizes属性缺失或写错，导致srcset失效；sizes必须真实反映CSS布局宽度，否则浏览器按100vw估算，错误选择远超需求的大图。
浏览器加载了最大尺寸图片，不是它“选错了”，而是你没告诉它这张图在页面上实际占多宽——sizes 属性缺失或写错，srcset 就形同虚设。
为什么写了 srcset 但浏览器还是拉下 2400w 的图
根本问题出在 sizes：它不参与渲染，只负责“告诉浏览器：这张图在当前视口下会显示成多宽”。浏览器拿这个宽度去匹配 srcset 里带 w 描述符的候选图，挑最接近且不小于该宽度的那张。
- 如果
sizes="100vw"，桌面端视口 1920px，它就按 1920px 算，哪怕容器 CSS 只有width: 720px，也会选 2400w 图 - 如果完全没写
sizes，部分浏览器（尤其是 Safari 旧版）会退化为按视口全宽估算，直接忽略srcset -
sizes值必须和真实 CSS 布局对齐：先写好@media (min-width: 768px) { .hero-img { width: 720px; } }，再转成sizes="(max-width: 767px) 100vw, 720px" - 父容器有
padding: 0 20px？视口宽 390px 时有效宽度 ≈ 350px，sizes得写成"(max-width: 767px) 350px, 720px"，不能硬套 100vw
picture 中 source 顺序错位导致 WebP 加载失败
Safari 13 及更早版本不支持 image/webp，但它会从上到下解析 <source>，遇到第一个 media 匹配且 type 受支持的就停。如果你把 <source type="image/jpeg"> 放前面，Safari 13 就永远卡在这条，根本不会往下看 WebP。
-
WebP/AVIF 必须排在 JPEG/PNG 前面：<source type="image/webp">→<source type="image/jpeg"> -
type值拼错（如type="image/webp;"多了个分号）会导致整条<source>被跳过 -
media和type是 AND 关系：两个条件都满足才启用该<source> - 冗余断点要删掉：
<source media="(min-width: 1440px)">如果 CSS 根本没定义这个断点，就是白占 HTML 体积
img 没设 width 和 height 会拖垮 LCP
没设内联 width/height 的 <img> 在加载前不占空间，内容会突然下移。这不只是视觉抖动，它直接拉长 LCP（最大内容绘制），让浏览器误判“首屏关键内容还没出来”，进而提前加载更大图来抢时间，反而推高带宽消耗。
立即学习“前端免费学习笔记（深入）”；
- 必须填原始图比例：1200×800 的图，就写
width="1200" height="800" -
object-fit: cover不解决占位问题，它只控制裁剪；容器尺寸仍由width/height或aspect-ratio决定 - 推荐双保险：
<img width="1200" height="800">+ CSSaspect-ratio: 1200 / 800；Safari 旧版可用padding-top技巧降级
超大图不能靠前端缩放，必须预生成多档位
直接 <img src="banner-10MB.jpg"> 即使加了 sizes，浏览器也只会下载这张图再缩放——它没能力在客户端实时降质或裁剪，10MB 还是得全量拉下来。营销页高峰期 CDN 带宽账单飙升，八成来自这种“假响应式”。
- 必须预生成多尺寸图：
banner-480w.jpg、banner-800w.jpg、banner-1200w.jpg等 - CDN 需配置识别
Accept请求头，才能根据<source type="image/avif">正确回源或返回缓存 -
srcset里不能混用w和x描述符，部分 Android 浏览器会直接忽略整条srcset - 同一
<source>内若同时出现media和type，两者必须都满足，否则跳过
真正麻烦的不是语法写不对，而是 CSS 布局改了但 sizes 没同步更新，或者 srcset 提供的宽度候选值和 sizes 计算出的目标物理像素不匹配——比如视口 > 768px 时 sizes 给的是 33vw，但你只提供了 480w 和 1200w，中间缺档，浏览器只能选 1200w。
