关键不在多而在准，根本原因是sizes未准确告知浏览器图片在布局中的实际宽度，导致小屏加载1200w大图；sizes必须覆盖所有断点、单位统一、与CSS布局严格对齐，且最后一项不可省略媒体条件，否则整条失效。
响应式图片列表不是靠“写一堆图片标签+一堆媒体查询”堆出来的，而是靠结构语义清晰、CSS 控制精准、浏览器行为可预测的组合。关键不在多，而在准。
为什么 img 加 sizes 配对总出错？
最常见的失效现象：小屏下加载了 1200w 的图，Network 面板里明明有更小的资源，但浏览器就是不选。根本原因不是 srcset 写错了，而是 sizes 没告诉浏览器“这张图在当前布局里实际占多宽”。
-
sizes是字符串，不是 CSS；它不能写calc()，也不能依赖父容器实时计算 - 必须覆盖所有断点，且每段值要和真实 DOM 渲染宽度一致——比如卡片在 768px 断点下只占容器 1/3 宽，
sizes就得写"(max-width: 768px) 33vw"，而不是偷懒写"100vw" - 最后一项不能省略媒体条件；写成
"(max-width: 768px) 100vw, 33vw"会导致整个属性被浏览器忽略 - Safari 12.1 之前不支持
w描述符，sizes再准也白搭，得用<picture>回退
<picture> 的 media 属性为什么静默失效？
浏览器不会报错，但 Network 面板里根本看不到对应 <source> 的请求——说明它压根没匹配上。这不是 JS 逻辑问题，是媒体查询语法本身被拒之门外。
-
media="(max-width: 768px)"正确；media="max-width: 768px"（缺括号）或media="768px"（非查询）直接无效 - 避免断点重叠：
max-width: 768px和min-width: 768px在 768px 宽度时会同时命中，但只有前者生效，后者被跳过 - 冗余前缀如
screen and (...)在部分旧环境可能触发兼容性降级，建议只写核心条件 -
<source>必须在<img>之前，否则浏览器按顺序解析时直接 fallback 到<img>
CSS 媒体查询控制背景图切换时，DOM 结构怎么写才不翻车？
用 background-image 实现艺术导向型适配（比如移动端用横构图、桌面端用竖构图），最怕的就是结构膨胀——为每个设备写一套 wrapper，后期加 20 张图就得维护 40 个 class。
立即学习“前端免费学习笔记（深入）”；
- 所有卡片共用一个语义化容器，比如
<article class="card">，不要拆成.card-mobile和.card-desktop - 背景图切换全交给 CSS：
@media (max-width: 600px) { .card { background-image: url(stamp-s.webp); } } - 悬停、阴影、动画等交互样式只在桌面断点启用，移动端用
display: none或transform调整 overlay 方向来复用元素 - 切忌用 JS 动态插入 background URL——FOUC 风险高，且不利于爬虫和打印样式
viewport 标签放错位置，后面所有响应式都白忙活
如果 <meta name="viewport" content="width=device-width, initial-scale=1.0"> 没生效，浏览器就按默认 980px 宽度渲染页面，srcset、sizes、@media 全部算错——图片撑破屏幕、横向滚动、缩放失灵都是典型症状。
- 必须放在
<head>最顶部，不能在<body>里，也不能动态插入 - 内容不能写成
width=375或加user-scalable=no（后者禁用缩放违反无障碍规范） - SSR 渲染漏掉这行，真机首次加载时布局就已锁定，后续 JS 补救无效
- 同一页面重复声明两次，可能导致某些 UA 行为异常，务必检查源码确认仅出现一次
真正难的不是写出能跑的代码，而是让浏览器在各种设备、各种 UA、各种网络条件下，都按你预设的逻辑去选图、渲染、响应。每一步都要验证 computed styles、network 请求、viewport 状态，而不是只看“看起来像不像”。
