transform: scale() 触发GPU合成层并用双线性插值缩放，导致非整数缩放比时模糊；根源是图源分辨率与DPR不匹配，应改用srcset/sizes加载高倍图而非依赖CSS缩放。
因为 transform: scale() 把图片拎进了 GPU 合成层，浏览器用双线性插值重采样——只要缩放比不是整数（比如 scale(1.2)），就必然模糊；它不换图源，也不对齐物理像素，只管“用力拉伸/压缩”当前这张位图。
transform 缩放触发 GPU 合成层，文字和图片都降级为位图渲染
静态图片用 img 标签加载时，浏览器默认走主图层光栅化，能保留亚像素细节；但一旦加了 transform: scale()，哪怕只是 scale(1)，Chrome/Safari 都会强制创建独立合成层，把整块内容转成纹理再缩放。GPU 插值算法（如双线性）对非整数缩放比天然不友好，边缘毛、文字虚、图标锯齿全由此来。
- 验证方式：打开 Chrome DevTools → Layers 面板 → 悬停缩放元素，看到红色图层框就确认已进 GPU 合成
-
will-change: transform或translateZ(0)不是解药，它们只加速进层过程，不改变插值逻辑 - 移动端 Safari 对 sub-pixel 更敏感，
scale(1.01)在 iPhone 上可能比 Chrome 更糊
scale() 的值不是整数，物理像素永远对不齐
缩放后模糊的表象是“看不清”，根源是坐标落在了小数像素上。比如容器宽 375px，transform: scale(1.3) 算下来位移或尺寸含 0.5px 偏差，浏览器无法把一个物理像素“劈开”渲染，只能插值混合周边颜色。
- 避免
translate(-50%, -50%)居中：父容器宽度为奇数时，50% 就是 xxx.5px - JS 动态计算需校准：
Math.round(value * window.devicePixelRatio) / window.devicePixelRatio - CSS 里慎用
calc(50% - 0.5px)这类表达式——它不解决根本问题，只是碰巧凑整
真正该缩放的是图源本身，不是靠 transform “拉扯”一张图
transform: scale() 是视觉欺骗，它不加载更高清资源；而移动端模糊的根因永远是图源分辨率 × DPR 不匹配。你让一张 375×200 的 @1x 图在 DPR=3 的 iPhone 上放大 1.5 倍，等于拿 375px 宽的图去撑 1689 物理像素宽——插值糊是唯一结果。
立即学习“前端免费学习笔记（深入）”；
- 正确路径：用
srcset+sizes让浏览器加载@2x或@3x图，再用max-width: 100%控制布局尺寸 - 背景图同理：必须配合
@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 2dppx)切图 + 显式background-size: 750px auto - 构建工具要放行
@2x.jpg文件名，Nginx/CDN 不能拦截@符号导致 404
最常被忽略的一点：模糊是否发生，取决于图源加载那一刻是否命中 DPR、路径是否可达、background-size 是否显式声明——这些全在 transform 执行之前就决定了。后面加再多 image-rendering 或 will-change，都是在给错误的前提打补丁。
