问题的根本原因，其实在于图片资源没有和设备像素比（DPR）正确匹配。想把高分屏背景图模糊的问题真正解决，通常需要同时满足三个关键条件：准备好@2x/@3x图片资源、完整配置复合媒体查询（-webkit-min-device-pixel-ratio与min-resolution要同时存在），以及明确设置background-size（例如750px auto）。这三点缺少任何一项，最终显示效果都很难彻底清晰。
由于图片分辨率没有匹配设备像素比（DPR），浏览器只能对1x图片进行插值放大处理——这并不是background-size参数设置错误，而是从源头上就没有切换到合适的高清图。
为什么 background-size: cover 还是模糊
cover只负责控制背景图的缩放方式，并不会增加图源本身的物理像素数量。在iPhone 14（DPR=3）这类高分屏设备上，一张100×100px的@1x.png会被放大为300×300物理像素进行渲染，浏览器通过插值算法补足中间像素，结果往往就是边缘发虚、细节变差，尤其是文字和线条部分更容易出现模糊感。
- 开发时在Chrome模拟器里看起来正常，到了真机Safari却明显发糊：原因是模拟器DPR通常固定为2，而真机DPR会随着机型变化（例如iPhone 15 Pro Max为3，部分安卓机型可能是2.75）
- 即使设置了
background-size: 750px auto，如果背景图仍然是bg.jpg这类1x资源，最终依旧会模糊 background-size: 100% 100%对于非矢量图片来说，基本等于主动拉伸变形，通常应谨慎使用
image-set() 为什么没生效
很多时候并不是写法有问题，而是浏览器根本没有正确识别。Firefox截至目前（v128）依然完全不支持image-set()；而多数安卓WebView只识别-webkit-image-set()，并且通常要求图片路径使用绝对路径，单位也必须写成dppx或带x后缀的格式。
- 如果在DevTools中看到
background-image: image-set(...)整行被划掉 → 说明浏览器不支持该语法，会直接忽略整条声明 - 如果Console报错
Failed to parse value for 'background-image'→ 通常是单位写错，例如写成了2而不是2x - 只加载了
@1x.png，却完全没有请求@2x.png→ 很可能是-webkit-前缀版本没有写在前面，Safari 16.4+在某些情况下会直接跳过整条规则
media query 必须同时写两套条件
如果只写@media (min-resolution: 2dppx)，会漏掉iOS 9–12上的Safari；如果只写@media (-webkit-min-device-pixel-ratio: 2)，在新版Chrome、Firefox、Edge中又可能无法稳定生效。
- 正确做法是使用逗号分隔的复合条件：
@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 2dppx) - 1x规则必须放在最前面作为fallback，否则某些老旧浏览器可能会直接忽略后续所有media query
- 即便切换到了
@2x.jpg，如果没有同步设置background-size: 750px auto→ 高分辨率图片仍可能被再次缩放，清晰度反而下降
构建和部署环节最容易出问题
即使已经写好了media query，也准备了@2x高清图片，页面上线后仍然发糊——这类问题往往出在前端构建工具或服务器部署配置上。
- Vite或webpack有时会默认过滤带
@的文件名（误判成PostCSS相关语法），需要在vite.config.js中额外配置assetsInclude - 部分CDN或Nginx配置会限制
@符号，导致像icon@2x.png这样的资源请求直接返回404 - 图片路径层级、文件扩展名必须完全一致，只能是后缀不同；同时三行声明中的引号类型（单引号或双引号）也要保持统一
真正棘手的地方恰恰在这里：DPR本身是运行时变量，但CSS媒体查询和image-set()本质上都依赖静态解析。也就是说，一旦业务场景涉及动态主题切换、DPR自适配，甚至还叠加了Canvas重绘需求，仅靠CSS兜底通常并不现实。这种情况下就必须交给JS处理，通过读取window.devicePixelRatio，再重新设置缓冲区，才能保证高分屏下的显示清晰度。
