不少开发者在构建响应式图片时都会用到标签，但在2x视网膜屏上一检查，发现图片依然模糊不清，着实令人沮丧。这背后的核心原因其实并不复杂：标签本身并不会自动适配高分辨率屏幕，它仅仅提供了一个选择容器，真正起关键作用的是上的srcset配合x描述符，而且必须带有一个src属性。否则，所有高DPR设备都会静默回退到默认图片，你的适配代码就等于形同虚设。

为什么明明写了却始终加载同一张图片

这是最容易被忽视的失效场景。浏览器并不会主动猜测你想适配2x屏幕——它只会严格按照的条件进行匹配，一个条件都匹配不上时就直接使用。常见的问题主要有以下几种：

• media属性值写错：比如media="max-width: 768px"（缺少括号）或media="768px"（非完整的媒体查询语句），浏览器会直接忽略该
• srcset单独出现但没有搭配media或type：这个不会参与选择，相当于白写
• 缺少src：图片区域会直接留空，不是报错，而是静默失败
• Network面板中看到blocked:mime-type：说明服务器返回的Content-Type与你声明的type="image/webp"不一致（比如返回了text/plain）

srcset必须使用x描述符，且顺序不可颠倒

要适配视网膜屏（DPR=2/3），只能识别1x、2x、3x这种写法；w描述符是另一套逻辑，除非你同时配置了sizes并按布局宽度计算，但那不是本文讨论的重点。关键要点如下：

• 正确的写法：srcset="photo.jpg 1x, photo@2x.jpg 2x, photo@3x.jpg 3x"
• 务必将最高倍率的图片放在最后：浏览器从左到右依次匹配，遇到第一个满足DPR的就停止；如果3x放在前面，2x设备永远选不到2x图片
• 不要混用描述符：photo-400w.jpg 400w, photo@2x.jpg 2x属于未定义行为，Chrome可能会直接忽略整个srcset

的src不是可选项，而是必须的兜底方案

老旧浏览器（如IE、旧版Safari）以及部分低版本Android WebView完全不解析srcset，只会读取src。如果遗漏了它，整个图片就会一片空白。实战中的建议包括：

• src应该指向一个中等清晰度、体积适中的版本（比如800w的JPEG），既不在小屏设备上浪费带宽，也不在桌面端显得模糊
• alt属性必须存在且有实际意义，否则可访问性会出问题
• 即使你只打算支持现代浏览器，也千万别省略src——当缓存失效、CDN配置错误、MIME类型错位时，它就是最后一道防线

调试时优先查看Network面板中的实际请求头

不要轻信“我写了2x就一定能加载2x图片”。打开DevTools → Network → 刷新，点开图片请求，检查Request Headers：

• 有没有Sec-CH-DPR？如果没有，说明浏览器根本没有启用DPR感知逻辑（可能是禁用了UA client hints，或者页面没有声明）
• 响应头Content-Type是否与type属性完全一致？大小写、空格、分号都不能有差异
• 加载的是哪一条？右键点击图片 → “Copy → Copy element”，查看实际渲染所用的路径

真正容易被忽视的关键点在于：断点的互斥性、src的兜底强度、以及服务器返回的MIME类型是否与前端声明完全吻合——这三个地方一旦出错，连window.devicePixelRatio是多少都变得无关紧要了。