单纯用 window.devicePixelRatio 设置 img.src 容易失效，因其仅在页面加载时读取一次，无法响应窗口拖拽、系统缩放、DPR突变或iOS横竖屏重排等动态场景，导致图片错配、模糊或带宽浪费；必须配合 srcset/fallback、变化监听（如 matchMedia）及资源准备。
直接结论：不能只靠 window.devicePixelRatio 动态改 img.src 就完事，必须配合资源准备、降级策略和变化监听，否则在窗口拖拽、缩放或 DPR 突变时会卡在模糊状态。
为什么单纯用 window.devicePixelRatio 设置 src 容易失效
常见错误是页面加载时读一次 window.devicePixelRatio，然后拼出 icon@2x.png 赋给 img.src，之后就不管了。但现实场景中：
- 用户把浏览器窗口从 MacBook（DPR=2）拖到外接 1080p 显示器（DPR=1），图片不会自动切回 1x 版本，仍强行渲染 2x 图 → 浪费带宽 + 可能失真
- Windows 用户调高系统缩放（125% → DPR=1.25），
window.devicePixelRatio变为非整数，而你只准备了@2x和@1x，没匹配项 → 回退到低清图 - 移动端横竖屏切换时，部分 iOS 设备不触发
resize，但 DPR 实际未变，布局重排后图片尺寸被 CSS 拉伸 → 模糊重现
srcset 是首选，但得写对单位和 fallback
srcset 让浏览器自己选图，比 JS 手动控制更可靠、更早发起请求（HTML 解析阶段就预加载）。但它不是“写了就清晰”，关键在参数组合：
- 必须提供
src属性作为所有浏览器的 fallback，且这张图分辨率不能太低（建议至少 800w 宽，别用 400w 的小图） - 用
x描述符时，只适配 DPR，不响应视口宽度 —— 适合固定尺寸图标：<img src="logo.png" srcset="logo.png 1x, logo@2x.png 2x, logo@3x.png 3x"> - 用
w描述符时，必须配sizes，否则浏览器无法换算 —— 适合响应式内容图：<img src="photo-800.jpg" srcset="photo-400.jpg 400w, photo-800.jpg 800w, photo-1200.jpg 1200w" sizes="(max-width: 480px) 100vw, (max-width: 960px) 50vw, 33vw"> - 别混用
w和x在同一个srcset里，整个属性会被浏览器忽略
需要 JS 动态干预的三个真实场景
当 srcset 不够用时，才上 JS。典型场景有：
-
Canvas 内绘图用的图片资源：Canvas 渲染缓冲区按 DPR 放大后，若
drawImage加载的是 1x 图，依然模糊。此时需动态拼 URL：img.src = `/api/avatar/${id}?dpr=${Math.round(dpr)}`，后端返回对应分辨率图 -
背景图（
background-image）：CSS 不支持srcset，可用image-set()，但 Firefox 仅支持 fallback；更稳的方式是 JS 切 class：el.classList.toggle('dpr-2', dpr >= 2)，再用 CSS 媒体查询兜底 -
第三方组件无法配置
srcset（如某些 UI 库的 Avatar 组件）：监听matchMedia('(resolution: 2dppx)')或resize事件，检测window.devicePixelRatio变化后，手动更新组件内部img元素的src
容易被忽略的兼容性与性能细节
很多方案看似可行，上线后才发现坑：
-
image-set()在 Firefox 中不解析多倍图，只走url()fallback；Safari 对image-set()的2x支持稳定，但3x在旧版本可能被忽略 - Webpack/Vite 构建时，静态
@2x文件若没配置插件自动补路径，打包后 404 —— 需确认vite-plugin-imagemin或自定义resolve.alias已生效 - Canvas 按 DPR 放大后，内存占用是平方级增长（DPR=3 → 像素量 ×9），对长列表中的 Canvas 卡片要限制最大 DPR（比如 cap at 2.5），避免低端安卓机 OOM
- 不要在每次
resize里都重新设置img.src，加防抖（setTimeout+ 清除）或只在dpr值实际变化时才更新
