响应式图片必须配合srcset、sizes和viewport标签才能生效；仅用max-width:100%纯css缩放不减少下载体积，浏览器仍加载大图，导致移动端带宽浪费、首屏变慢、解码卡顿。
响应式图片不是“加了就快”，而是必须配合 srcset、sizes 和正确尺寸策略，否则浏览器大概率加载一张桌面图在手机上缩放显示——白浪费带宽，首屏更慢。
为什么只写 max-width: 100% 不算响应式图片
纯 CSS 缩放不改变实际下载的图片体积。浏览器解析 HTML 时，如果 <img> 只有 src，它根本不知道这张图在手机上该占多宽，只能按默认行为（比如加载最大可用源或 fallback 图）发起请求。
- 实测中，一张 1200px 宽的 JPG 在 iPhone 上被
max-width: 100%缩到 390px，仍下载全部 1200px 像素数据 - 移动端网络延迟高，大图解码也更耗 CPU，容易卡顿甚至触发 iOS 的图片降级渲染
- 在线运行环境（如 CodePen）尤其明显：没
srcset就等于没声明资源意图，sizes更无从生效
srcset + sizes 怎么配才不选错图
关键不是“列得多”，而是让浏览器能准确推算出“当前视口下，这张图渲染宽度是多少”，再结合设备像素比（DPR）选出最匹配的源。
-
srcset用w描述符：例如"photo-400w.jpg 400w, photo-800w.jpg 800w, photo-1200w.jpg 1200w"—— 这些数字是图片固有宽度，不是容器宽度 -
sizes必须写明确的媒体条件：例如"(max-width: 768px) 100vw, 50vw"，表示“小屏时占满视口宽，大屏时只占一半” - 漏掉
viewport元标签：<meta name="viewport" content="width=device-width, initial-scale=1">，vw单位会失效，sizes形同虚设 - 不要写
sizes="100vw"一刀切——如果图片在 flex 容器里被压缩成 300px，浏览器却按 100vw（比如 390px）去选图，仍可能偏大
哪些地方加 loading="lazy" 反而坏事
懒加载只适用于“非首屏、无视觉依赖、不参与布局计算”的图片。加错位置会直接破坏用户体验和 SEO。
- 首屏关键图（如
<header></header>中的 Logo、主 Banner）必须去掉loading="lazy"，否则旧版 Safari 可能完全不加载 -
<img>作为 CSS 背景图时，loading属性无效——得改用<picture></picture>或内联 SVG - 带
srcset的图可以共存loading="lazy"，但前提是sizes准确；否则浏览器误判视口宽度，可能加载过小图导致模糊 - 服务端渲染（SSR）页面中，若首屏
<img src="...">已写死，又加了loading="lazy"，部分安卓 WebView 会跳过加载
<picture></picture> 什么情况下非用不可
当需要根据屏幕尺寸切换构图（art direction），或强制提供现代格式回退时，<picture></picture> 是唯一可靠方案。
- 艺术方向场景：桌面端展示全身人像，移动端只保留面部区域——单靠
srcset无法裁切，必须用<source media="(max-width: 768px)" srcset="face.webp"></source> - 格式回退：想用 WebP 但需兼容老 IE/旧安卓，
<source type="image/webp" srcset="photo.webp"><img src="photo.jpg" alt="..."></source>是标准写法 - 注意：
<source></source>的media是 CSS 媒体查询，不是 JS 判断；浏览器按顺序匹配，第一个满足的生效，后续忽略 - 别为了“看起来高级”硬套
<picture></picture>：如果只是分辨率适配，<img srcset...>更轻量、兼容性更好
真正容易被忽略的是 sizes 的动态准确性——它不像 CSS 那样实时重算，而是在 HTML 解析阶段就被浏览器锁定。一旦容器宽度受 JS 或 flex/grid 布局影响发生变动，sizes 就可能失准。这时候要么用 JS 动态改 sizes 属性，要么提前在 CSS 里把容器宽度收束到可预测范围。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
