srcset仅条件分发图片，不压缩转码；需配合sizes属性才能让浏览器准确选择合适版本，否则可能全加载大图；HTML宽高属性防布局偏移，非缩放；真正优化依赖构建或服务端处理。
srcset 不自动优化图片，只做「条件分发」
srcset 本身不压缩、不转码、不调整质量，它只是告诉浏览器：「这里有多个尺寸/像素密度的版本，你按需选一个下载」。是否真正加载更小的图，取决于浏览器根据 viewport 宽度、设备像素比（dpr）、网络条件（如果配合 media 或 imagesizes）做出的决策。
常见错误现象：
- 写了
srcset但所有设备都加载了最大的图 → 没配sizes，浏览器默认按 100vw 计算，无法准确预估渲染宽度 - 用
srcset列了2x图但没给width或height→ 布局抖动，尤其在慢网下 - 把 WebP 和 JPEG 混在同一个
srcset里 → 无效，srcset只支持同一格式不同分辨率，多格式要用<picture></picture>
sizes 属性才是固定尺寸场景的关键
当容器是固定宽高（比如 width: 300px; height: 200px），或响应式断点下尺寸确定（如「在 768px 以上总是占栅格 4 列」），sizes 就必须显式声明，否则浏览器无法判断该选哪个 srcset 项。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 固定尺寸容器直接写
sizes="300px" - 响应式栅格（如 Bootstrap 的 col-6）可写
sizes="(min-width: 768px) 50vw, 100vw" - 避免写死
sizes="100vw"—— 它忽略边距、滚动条、flex gap 等真实占用空间，容易选大 - 用 Chrome DevTools 的 Network 面板 + 「Disable cache」+ 切换 device，验证实际加载的是哪个 URL
HTML 固定尺寸（width/height）不是为了缩放，而是防布局偏移
HTML 中写 <img width="300" height="200"> 不会让图片“被压缩成 300×200”，它只提供**渲染前的占位尺寸**，防止加载完成前页面跳动（CLS）。CSS 里的 width/height 才真正控制显示大小。
关键差异：
- HTML
width/height是整数，单位是 CSS 像素，且会触发浏览器提前计算 aspect ratio（现代浏览器据此做 CLS 优化） - CSS
width: 300px可以是任意值（百分比、rem、clamp），但若没设 HTML 属性，初始渲染时宽高为 0，导致重排 - 响应式图 + 固定宽高属性 = 必须配合
aspect-ratio或object-fit，否则拉伸变形
真正优化图片得靠服务端或构建流程
前端仅靠 srcset + sizes 解决不了根本问题：原始图太大、格式落后、缺乏感知压缩。它只是「精准投送」的前提。
落地要点：
- 构建时用
sharp（Node）或libvips批量生成320w、768w、1200w等尺寸，并统一转 WebP/AVIF - 服务端（如 Nginx、Cloudflare）开启
Accept头识别，对支持 AVIF 的请求返回 AVIF 版本（需搭配<picture>fallback） - 慎用「自动 srcset 生成」插件（如某些 WordPress 插件）—— 它常把原图缩放后塞进
srcset，质量差还体积大 - 用
<img src="fallback.jpg" srcset="small.webp 320w, medium.webp 768w, large.webp 1200w" sizes="(max-width: 320px) 280px, (max-width: 768px) 720px, 1100px" alt="...">
，确保每个环节可验证
最易被忽略的一点：即使 srcset 和 sizes 全写对了，如果 CDN 没开缓存、图片没启 Gzip/Brotli、响应头缺少 Cache-Control，加载速度照样上不去。优化是链条，不是单点开关。
