配合 srcset（w 描述符）与 sizes 是实现轻量、可靠响应式图片的核心方案：srcset 提供多分辨率候选图，sizes 告知浏览器各断点下图片的渲染宽度，二者协同使浏览器在 html 解析阶段即可精准选择最适配资源，避免小屏加载大图。
用 <img> 配合 srcset 和 sizes 就能实现轻量、可靠、无需 JS 的响应式图片加载——90% 的场景根本不需要封装“组件”，硬套框架或自建 wrapper 反而破坏浏览器原生预加载逻辑。
为什么别急着写“组件”，先搞懂 srcset + sizes 怎么选图
浏览器在 HTML 解析阶段就发起图片请求，此时 CSS 还没生效。所以仅靠 width: 100% 或媒体查询控制显示尺寸，完全无法阻止小屏加载 2000w 大图。
-
srcset告诉浏览器“我准备了哪些图”，必须用w描述符（如photo-800w.jpg 800w），它表示该图的固有宽度是 800 CSS 像素 -
sizes告诉浏览器“这张图在当前布局下会占多宽”，必须是条件表达式，比如(max-width: 768px) 100vw, 50vw，不能写死成50vw - 浏览器用
sizes算出渲染宽度（例如 390px 视口 × 0.5 = 195px），再乘以设备 DPR（如 iPhone 13 是 3），得出所需物理像素（≈585），最后从srcset中挑最接近且不小于它的w图
sizes 写错导致大图小屏加载的典型表现
常见错误是把 sizes 当成“最大宽度”来写，结果桌面端加载小图、移动端反而出大图。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 父容器有
max-width: 600px，但sizes="100vw"→ 桌面端仍尝试加载 1920w 图 - CSS 里写了
@media (min-width: 1200px) { width: 33vw; }，但sizes漏掉这条规则 → 浏览器 fallback 到默认值（通常是 100vw），选错资源 - 用了
rem单位布局，但sizes直接写30rem→ 浏览器不认识rem，当作无效值处理，行为不可控
什么情况下才真需要 <picture></picture>？不是切分辨率，而是换构图或格式
<picture></picture> 不是“高级版 <img>”，它是为两类明确需求设计的：美术裁剪（art direction）和格式降级（format fallback）。
- 小屏用竖构图头像，桌面用横构图全景 → 用
media="(max-width: 768px) and (orientation: portrait)"匹配竖图srcset - 想优先发
image/avif，不支持就跳过，再试image/webp，最后 fallback 到image/jpeg→ 必须按支持强度降序写<source></source>，且type不回退 -
<img>必须放在<picture></picture>最末尾，且带src和alt—— 它是唯一强制渲染的节点，漏掉就白写 -
<source></source>顺序错了（比如把宽泛的(min-width: 400px)放前面），高 DPR 设备永远匹配不到后面的高清规则
现代框架里别手写 <picture></picture>，优先用内置图片逻辑
Next.js 的 <image></image>、Nuxt 的 <nuxtimg></nuxtimg>、Astro 的 <image></image> 组件，底层都自动注入 srcset/sizes，并处理宽高比、懒加载、CDN 转换等细节。自己拼 <picture></picture> 容易漏掉 decoding="async"、fetchpriority="low" 或 loading="lazy" 这些影响性能的关键属性。
真正容易被忽略的是：所有这些方案都依赖你提供一组合理梯度的图片尺寸（比如 400w / 800w / 1200w / 1600w），而不是只塞两个极端档位；以及，sizes 表达式必须和真实 CSS 渲染结果严格对齐——差一个像素，选图就可能偏差一倍。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
