必须同时提供@2x/@3x图、用复合媒体查询（如@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 2dppx)）命中、显式设置background-size（如750px auto），三者缺一不可，否则高DPR屏仍会模糊。
background-image怎么适配2x/3x屏不模糊
直接写 background-image: url('bg.jpg') 在 iPhone 或高 PPI Android 机上必然发虚，因为浏览器把 1x 图强行拉伸渲染，插值填充物理像素。必须同时满足三件事：提供 @2x/@3x 图、用复合媒体查询命中、显式设置 background-size。
常见错误是只换图不设尺寸，或只写 @media (min-resolution: 2dppx) 漏掉 iOS 9–12 的 Safari：
-
@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 2dppx)才能覆盖主流浏览器 -
@media (-webkit-min-device-pixel-ratio: 3), (min-resolution: 3dppx)同理，顺序不能颠倒（1x 规则必须在最前） -
background-size必须写具体值，比如设计稿宽 750px 就写background-size: 750px auto；不要用cover配合高倍图——裁剪基准在不同 DPR 下偏移不可控 - 文件名必须严格匹配：
bg.jpg/bg@2x.jpg/bg@3x.jpg，路径、扩展名、大小写全一致
srcset + sizes 比 background-image 更可靠
HTML 中的 <img> 支持原生多倍图选择机制，比 CSS 的 background-image 更健壮：它能在 HTML 解析阶段就发起请求，支持预加载，且无需手动维护多套媒体查询规则。
关键不是堆图，而是给浏览器可计算的信息：
立即学习“前端免费学习笔记（深入）”；
-
srcset必须带w单位（如photo-800w.jpg 800w），不能混用x和w，否则整个属性被忽略 -
sizes必须存在，且要反映图片在布局中的实际宽度，例如sizes="(max-width: 480px) 100vw, 50vw" - 避免只用
2x描述——响应式布局下图片宽度会变，x无法表达这种动态关系 - WebP/AVIF 图必须用
<picture>包裹并提供 fallback，不能只替换src
image-set() 函数的兼容性与性能陷阱
image-set() 看起来简洁，但实际落地有硬伤：Firefox 只支持 url() fallback 写法，不解析 image-set() 本身；Chrome/Safari 虽支持，但它纯运行时计算，不触发预加载，首屏 LCP 明显劣于 srcset。
如果非要用，必须写两层 fallback：
.hero {
background-image: image-set(
"hero-1x.jpg" 1x,
"hero-2x.jpg" 2x,
"hero-3x.jpg" 3x
);
background-image: url("hero-1x.jpg");
}
注意：image-set() 不支持 w 单位，也不能和 sizes 配合；CDN 或构建工具（如 Vite）可能过滤带 @ 的文件名，上线前务必验证 bg@2x.jpg 能被直接访问。
构建和部署阶段最容易卡住的三个点
很多项目本地看着正常，上线就糊，问题不在代码逻辑，而在资源交付链路：
- Vite/Webpack 默认配置可能 strip 掉
@2x这类文件名（误判为 PostCSS 插件语法），需检查构建产物中是否存在bg@2x.jpg - Nginx/Apache 通常允许
@符号，但某些 CDN（如部分国内厂商）默认禁用，需显式开启或改用下划线命名（bg_2x.jpg） - 没加
<meta name="viewport">或缩放被禁用，会导致 layout viewport 和视觉 viewport 不一致，DPR 判断失准，媒体查询失效
真正决定清晰度的，从来不是某一行 CSS，而是图源精度、设备 DPR、浏览器选图逻辑、构建产物完整性这四者的咬合。漏掉任意一环，高清图也白搭。
