只写max-width:100%是假响应式，因它仅缩放渲染尺寸却不减少下载字节数；手机加载1920px图缩至375px显示，带宽浪费严重，真正优化需srcset+sizes或在请求阶段选对资源。
为什么只写 max-width: 100% 是假响应式
它只控制渲染尺寸，不减少实际下载的字节数。手机加载一张 1920px 宽的图，再缩到 375px 显示，带宽全花了，用户只看到 30KB 有效像素。
真正起作用的是 srcset + sizes 或 <picture></picture>，它们让浏览器在请求阶段就选对资源。
-
max-width: 100%必须和height: auto成对出现，否则比例崩坏 - 父容器是
display: flex时，子img要额外加min-width: 0，否则 flex 默认的min-width: auto会卡住收缩 - 仅靠 CSS 缩放无法解决“小图放大模糊”或“大屏加载小图不清晰”的问题
srcset 和 sizes 怎么配才不被浏览器忽略
漏写 sizes、混用 w 和 x 描述符、或 sizes 值与真实布局脱节，都会导致浏览器跳过整个 srcset，直接加载 src 回退图。
-
srcset中只能统一用w（如"small.jpg 480w, medium.jpg 768w"）或统一用x（如"low.jpg 1x, high.jpg 2x"），不能混写 -
sizes是字符串，不是 CSS，不支持calc()；但支持媒体查询语法，例如：sizes="(max-width: 480px) 100vw, (max-width: 768px) 50vw, 33vw" - 如果图片在栅格中占 1/3 宽，且断点从 768px 开始，
sizes就该是"(max-width: 768px) 100vw, 33.33vw"，不是硬写100vw - 旧版 Safari（12.1 之前）对
w描述符支持不全，iOS 旧设备可能只按 DPR 粗略匹配
什么情况下必须用 <picture></picture> 而不是 srcset
当需要艺术方向裁剪（比如手机裁人脸、桌面展全景）或强制格式回退（优先 WebP，降级 JPEG）时，<picture></picture> 是唯一解。
-
<source></source>的media和type是 AND 关系：浏览器跳过任何不满足其一的项 - 顺序决定优先级：最具体规则放最前，兜底的
<img>放最后 -
media="(max-width: 768px)"若写成767px，会导致匹配失效；type="image/webp"若拼错（如多写分号），整条<source></source>被跳过 - 旧版 Edge（EdgeHTML）解析
sizes时，媒体查询里有空格（如(max-width: 768px)）会导致整个属性失效
object-fit 和 aspect-ratio 是补位关键
它们不参与资源选择，但解决 CSS 布局中图片“填不满”或“被拉伸”的视觉问题。
-
object-fit: cover配合固定宽高容器，可替代暴力width/height拉伸；需加object-position微调焦点区域 -
aspect-ratio: 4/3可防网格中图片高度塌陷，尤其在懒加载未完成时；IE 不支持，可用 padding-top 百分比 hack 替代 - 背景图用
background-size: cover更轻量，但无法语义化、不可被屏幕阅读器识别，仅适合装饰性图像 -
loading="lazy"是性能标配，但别滥用在首屏关键图上；decoding="async"可进一步减少主线程阻塞
sizes 值随 CSS 布局变更后没同步更新，或者 srcset 提供的宽度候选值和实际视口物理像素严重不匹配——这种问题在开发阶段几乎不会报错，只会在真机弱网下悄悄拖垮体验。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
