应轮询检测 window.devicepixelratio 变化：用 requestanimationframe 实现精准、低开销的实时监听，并首次加载时立即执行；resize 事件不可靠，因缩放不必然改变窗口尺寸。
监听 window.devicePixelRatio 变化不触发？
window.devicePixelRatio 是只读属性，浏览器**不会在缩放时派发任何事件**。直接监听 resize 或 orientationchange 也大概率漏掉变化——比如 macOS Safari 手动缩放（Cmd +）、Chrome 地址栏折叠、甚至部分安卓 WebView 的动态 DPI 调整，都可能不触发这些事件。
真正可行的方案是轮询检测：
- 用
requestAnimationFrame（推荐）：比setInterval更精准、更省资源，且与屏幕刷新同步 - 仅当
window.devicePixelRatio值实际变化时才触发回调，避免无意义重复执行 - 注意首次加载时也要检查一次，因为初始缩放可能已在页面加载前完成
let lastRatio = window.devicePixelRatio;
function checkDPR() {
const current = window.devicePixelRatio;
if (current !== lastRatio) {
lastRatio = current;
handleDPRChange(current);
}
requestAnimationFrame(checkDPR);
}
checkDPR(); // 立即执行一次
为什么 resize 事件在缩放时有时不触发？
缩放（zoom）和视口尺寸变化（resize）本质不同：resize 只响应浏览器窗口宽高像素值变化，而缩放可能仅改变渲染比例，不改变 window.innerWidth/Height —— 尤其在移动端 Safari、桌面端 Chrome 的「页面缩放」模式下。
- PC 浏览器中，按
Ctrl/Cmd +缩放，resize通常不触发（除非窗口被强制重排） - 移动端 Safari 的「双指缩放」会触发
resize，但仅限于viewport设置为user-scalable=yes且未禁用缩放时 - 某些 Electron 或 WebView 容器会完全屏蔽
resize，但devicePixelRatio仍可读取
所以别依赖 resize 捕获缩放行为，它不是可靠信号源。
handleDPRChange 中该做什么？
常见误操作是立刻重绘 canvas 或替换图片 src —— 这容易引发抖动或重复加载。关键判断点在于：是否真的需要响应这次变化？
- 如果只是做响应式布局，
devicePixelRatio变化通常意味着物理像素密度变了（比如从 1x 切到 2x 屏），但页面缩放时它也可能变（如 Chrome 缩放到 125%，devicePixelRatio可能从 1 → 1.25）。二者语义不同，需区分场景 - Canvas 渲染：应同时检查
canvas.width/height与canvas.style.width/height比例，仅当devicePixelRatio影响了渲染清晰度（即canvas.style尺寸固定但设备像素比升高）时才重设canvas.width - CSS 媒体查询已覆盖大部分 DPI 场景，JS 层响应应聚焦于 Canvas、WebGL、自定义字体渲染等无法被 CSS 自动适配的逻辑
兼容性与边界情况要注意什么？
devicePixelRatio 在 IE 和旧版 Android Browser 中不可用（返回 undefined），但现代浏览器基本都支持。真正棘手的是以下情况：
- Windows 上 Chrome + 触控屏：系统级缩放（设置 > 显示 > 缩放与布局）会让
devicePixelRatio返回 1.25 / 1.5 / 2，但页面 JS 可能拿不到变化通知（尤其全屏 PWA）——必须靠轮询 - Safari 私密浏览模式下，
devicePixelRatio可能被限制为 1，即使设备是 Retina 屏 - 某些安卓 WebView（如微信内置）会伪造
devicePixelRatio值，始终返回 3，与实际不符；建议结合window.screen.availWidth / window.innerWidth做交叉验证
轮询本身开销极小，但别在非必要场景（比如纯静态页面）里加——它不是银弹，只是针对「缩放影响像素级渲染」这类明确需求的务实解法。
