17370845950

最常用场景是搭配width描述符与sizes属性：srcset列候选图及其自然宽度（如"small.jpg 480w"），sizes定义各断点下图片占位宽度（如"(max-width:480px)100vw"），浏览器据此选择最接近且不小于所需显示宽度的资源。

srcset 属性怎么配 width 描述符（最常用场景）

用 srcset 实现响应式图片，核心是告诉浏览器「不同视口宽度下该加载哪张图」。最稳妥、兼容性最好的写法是搭配 width 描述符 + sizes 属性：

• srcset 列出所有候选图及其自然宽度，例如："small.jpg 480w, medium.jpg 768w, large.jpg 1200w"
• sizes 告诉浏览器“在不同断点下，这张图将占据多少 CSS 宽度”，例如：sizes="(max-width: 480px) 100vw, (max-width: 768px) 50vw, 33vw"
• 浏览器根据当前视口宽度、设备像素比（dpr）、sizes 计算出所需显示宽度，再从 srcset 中选最接近且不小于该宽度的资源
• 别只写 srcset 不写 sizes —— 没 sizes 时浏览器默认按 100vw 计算，容易在窄屏下误载大图

@@##@@

HTML4 里根本没有 srcset，所谓“响应式图片加载慢”其实是手动适配的锅

HTML4 没有原生响应式图片机制，开发者只能靠 JS 动态换 src 或用 CSS 背景图 + 媒体查询。问题不在“HTML4 加载慢”，而在这些方案本身有硬伤：

• JS 方案：依赖 DOMContentLoaded 或 resize 事件，首屏往往先加载默认大图，再重载小图 → 白屏或闪动 + 多一次请求
• CSS 背景图：无法设置 alt，SEO 和可访问性差；background-size 缩放会模糊；无法通过 loading="lazy" 原生懒加载
• 服务端 User-Agent 识别：维护成本高，无法准确判断 DPR 和真实视口，容易错判高清屏

所以不是 HTML4 “慢”，而是没有语义化支持时，人写的补丁容易出错、冗余、不可控。

srcset 配 x 描述符适合固定尺寸组件（比如头像、图标）

当图片在页面中始终显示为固定 CSS 尺寸（如 width: 64px; height: 64px），用 x 描述符更直接：

• srcset="icon-1x.png 1x, icon-2x.png 2x, icon-3x.png 3x"
• 浏览器按设备像素比（window.devicePixelRatio）选择：DPR=2 就载 2x 版本
• 不用写 sizes，但必须确保 CSS 设定的宽高是固定的，否则缩放失真
• 注意：不能混用 w 和 x 在同一个 srcset 里，会整体失效

@@##@@

容易被忽略的关键点：src 是必填降级项，且不能省略

即使写了完整的 srcset，src 属性仍必须存在，原因有两个：

• 不支持 srcset 的老浏览器（如 IE、旧版 UC）会直接忽略 srcset，只加载 src 指定的图 —— 这是唯一兜底方式
• 部分爬虫和 RSS 阅读器只读 src，不解析 srcset，影响 SEO 和内容分发
• src 建议指向中等分辨率图（比如 768w 或 800px 宽），既不过于模糊也不过分浪费带宽

还有个隐藏陷阱：如果 src 指向的图尺寸远小于 srcset 中最小项（比如 src="tiny.jpg" 且只有 200px 宽），而页面实际需要 400px 显示，就会被拉伸模糊 —— 此时 src 不是“备用”，而是“强制 fallback 渲染源”。