浏览器加载模糊图的根本原因是srcset的2x描述符仅在图片占满视口宽度时可靠生效，一旦CSS限制宽度（如max-width: 600px），2x失去上下文而失效；同时sizes写错、单位非法、未覆盖全视口范围，或CDN参数与w值不匹配，均导致整个srcset被跳过，回退至src低分辨率图。
为什么只写 srcset 里的 2x 还是加载模糊图
因为浏览器在现代响应式布局中，2x 描述符只在图片“占满视口宽度”时才可靠生效；一旦 CSS 控制了图片宽度（比如 max-width: 600px），2x 就失去上下文，浏览器退而求其次，按 src 或默认规则选图——结果就是 DPR=2 的 iPad 加载了 800w 图，实际需要的是 1200w+。
-
2x是设备像素比导向，不是渲染宽度导向：它假设“1 CSS 像素 = 2 物理像素”，但前提是这张图真占了 100vw，否则无法反推所需物理像素数 - 混用
400w和logo@2x.png 2x在同一srcset中 → 整个属性被忽略，静默回退到src - 老 iOS Safari（≤12.1）根本不支持
w描述符，但支持2x；新 Chrome 则优先用w+sizes，2x只作 fallback - 验证是否生效，唯一方式是 DevTools → Network → 切换设备模拟器 → 看请求 URL 后缀和
Content-Length，别信“看起来清晰”
sizes 写错会导致所有 srcset 失效
sizes 不是 CSS，也不是建议值，它是浏览器计算“该加载哪张图”的唯一输入。写错就等于没写，整个 srcset 被跳过，直接走 src。
- 必须覆盖全部视口范围：例如
sizes="(max-width: 480px) 100vw, (max-width: 768px) 50vw, 33vw"—— 最后一项不能省略媒体条件，否则 Safari 会整个忽略 - 单位必须合法：
50vw✅，50%❌，50❌，50rem❌ - 必须与真实渲染宽度一致：如果 CSS 设了
width: 320px，但sizes还写100vw，浏览器就会去拉 1200w 图，哪怕你只显示 320 CSS 像素宽 - CDN 裁剪参数必须对齐：
hero-800.jpg?w=800必须配800w，写成?w=800 400w→ 浏览器跳过该项
<picture> 里 media 和 type 是 AND 关系，不是 OR
很多开发者以为写了 type="image/webp" 就能自动降级，其实浏览器只认“media 匹配且 type 可解码”的组合；任一不满足，就跳过这个 <source>，继续往下找。
-
media必须是标准 CSS 媒体查询语法：(min-width: 768px)✅，768px❌，screen and (min-width: 768px)❌（冗余关键词被忽略） -
type必须和服务端返回的Content-Type完全一致：路径是.webp，但服务端返回text/plain→ Chrome 标记为(blocked:mime-type) - 顺序决定优先级：把最具体规则（如
(min-width: 1440px) and (prefers-color-scheme: dark)）放前面，宽泛规则（如(max-width: 480px)）放后面 -
<img>不是可选项，是强制兜底：漏掉src或alt，图片区域留空，不报错，只是静默失败
高 DPR 屏幕下图片模糊的真正原因和修复点
模糊不是分辨率太高，而是渲染单元没对齐物理像素——浏览器用 800w 图去撑 1600 物理像素宽的区域，靠插值拉伸，必然糊。
立即学习“前端免费学习笔记（深入）”；
-
<img>必须带width和heightHTML 属性（不是 CSS），否则加载瞬间触发 layout 抖动，破坏渲染节奏 - CDN 返回的 WebP/AVIF 图必须确认支持对应 DPR：有些 CDN 默认只输出 sRGB，高色域屏下颜色失真，看似模糊
- 不要依赖
window.devicePixelRatio初始化一次就完事：外接显示器切换、系统缩放变更时，matchMedia('(resolution)')才能捕获变化 -
src必须指向中等分辨率图（如 800w 或 1024w），不是最小图；否则老浏览器或解析失败时，用户看到的就是不可接受的模糊
sizes 是否真实反映渲染宽度、srcset 的 w 值是否与 CDN 参数严格对齐、以及每个 <source> 是否同时满足 media 和 type 条件——少一个，就退化成单图加载。 
