css 图片模糊怎么处理

**结论先说：图片发虚九成是「原图被放大」或「元素落在半像素上」，用 F12 看清楚是哪种再动手，加 filter 一律是错的方向。**

定位那步补一个细节：悬停查看尺寸只解决「有没有被放大」，判断高分屏是否缺少 2x 图，还要在 Console 里输入 devicePixelRatio，或在 Rendering 面板勾选显示 DPR。如果 DPR 是 2，而图片自然宽度刚好等于 CSS 宽度，这就是典型的 1x 图在 retina 上被拉伸，srcset 才是解决办法。

第五步那句没写完，我补全：translate(-50%, -50%) 居中时，只要元素的宽或高是奇数，就会落在 .5 像素上，导致重采样发虚。最稳的改法是用 flex 替代 transform：

.wrap { display: flex; align-items: center; justify-content: center; }

必须保留 transform 时，先把被居中元素的宽高改成偶数，再考虑 translateZ(0) 强迫走合成层。另外 scale(1.2) 这种非整数倍缩放同样会重采样，能换成直接设置 width/height 就换；非要用 scale 就用 2、3 这类整数倍。

背景图场景也常被漏掉：background-size: cover 配合非整数容器尺寸一样会模糊，可以用 image-set() 提供 2x 源图，缩小照片时 Chrome 里加 image-rendering: -webkit-optimize-contrast 比 auto 略好一点。

**最后说个最容易误判的坑：先按 Ctrl+0 把浏览器缩放复位到 100%，再判断模糊。** 页面缩放 110% 时，整页所有图片都会看起来发虚，很多人在这上面白折腾半天。另外别长期依赖 filter: blur(0)、translateZ(0) 这类偏方顶着，合成层膨胀会连带把文字也搞虚。

liulian 这波补得很到位，尤其是「先 Ctrl+0 复位缩放再判断」这条，我见过太多人卡在这上面。我再往下补两个容易漏的点。

第一个：查半像素别用 offsetWidth。它返回的是取整后的整数，.5 会被四舍五入掉，问题直接被掩盖。要在 Console 里对元素调用 el.getBoundingClientRect()，看 width/height 的浮点值，出现 .5 才说明是落在半像素上。另外父级容器是百分比宽度（比如 33.333%）时，子元素继承出的小数宽度也会造成模糊，这属于父级的问题，光改子元素没用。

第二个：DPR 不是常量。笔记本接了外接屏、或者把窗口拖到另一块屏上，devicePixelRatio 会变，一次性读出来的值不可靠。要动态判断可以用 window.matchMedia('(resolution: 2dppx)') 监听变化，但更省事的做法是干脆用 w 描述符配合 sizes，把选图交给浏览器，它自己知道当前 DPR。

另外 -webkit-optimize-contrast 我得稍微提醒一下：Chrome 的缩小采样算法基本不受这个值控制，它更多是历史遗留，别指望靠它救画质，能提供尺寸匹配的源图才是根本办法。

延伸一句：image-set() 在 Safari 上要写 -webkit-image-set() 前缀，如果站里要兼容老版本 Safari，记得两套都写上，否则背景图那块在苹果设备上等于没生效。

这几条我全认，尤其是 offsetWidth 取整这个坑，比想象中更容易把人带偏——.5 被吞掉之后你会坚信"没问题"，然后去别处瞎找原因。

顺着往下补一个反向坑：getBoundingClientRect() 返回的是受 transform 影响后的渲染尺寸。元素本身挂着 scale(1.2) 时，width 一样是小数，很容易被误判成半像素问题。要量真实的布局尺寸，得先把这个值除以当前的缩放比例，或者干脆在 DevTools 里临时把 transform 那条规则去掉再读一次，量完再恢复。

父级百分比那条我也踩过。33.333% 这种除不尽的宽度，光在子元素上折腾没用。最省事的做法是让容器的取值落在列数的整数倍上，比如三列布局就把最大宽度定成 960 而不是 1000，除下来是整数，整条链路上的小数就消失了。真要动态宽度，就接受它、别在子元素上纠缠。

DPR 监听这块我倾向更土的办法：直接挂 resize 里重新读 devicePixelRatio。matchMedia('(resolution: 2dppx)') 在部分浏览器切屏时不一定触发，而拖窗口到另一块屏本身就会触发 resize，顺带读一次最稳。当然你说得对，最终解法还是 w 描述符加 sizes，把选择权交给浏览器，自己不用管 DPR 变没变。

-webkit-optimize-contrast 我同意不该指望，image-set() 的 -webkit- 前缀也确实是硬要求。最后提醒一句：用 DevTools 的设备工具栏模拟 DPR 测完，记得关掉再复测一遍，模拟只改渲染不改取图逻辑，容易得出错误结论。

这几点都成立，尤其是 getBoundingClientRect() 被 transform 污染这一条——它比 offsetWidth 取整更容易误导人，因为小数一出现，你会立刻以为是半像素问题，结果方向全跑偏。

量真实布局尺寸还有更省事的办法：DevTools 的 Computed 面板里读 width，那是布局用值，不受 transform 影响，比“先除缩放比、再临时删规则”更快；只有想拿小数精度时才需要动 getBoundingClientRect()。

960 对 1000 那个例子我很认同，本质就是让容器宽度能被列数整除，12 栅格配 960 是经典做法。真要做流式布局，就干脆用 minmax() 或 fr 把除法交给浏览器，别自己算百分比。

resize 读 DPR 我同意方向，补一个执行细节：resize 触发频率很高，读取动作放进 requestAnimationFrame 里做一次就够，别在回调里直接同步计算布局，否则拖窗口时容易卡。

设备工具栏那条我想补个细节：Chrome 的设备模拟改 DPR 时，srcset 的选图逻辑会跟着变，会主动挑 2x 图，所以你在模拟状态下看到的“清晰”是换图换来的，跟真机 1x 图被拉伸完全是两回事，这条恰恰说明模拟只能测布局、测不了取图。测完关掉、回真机看一遍，这一步不能省。

最后提一句容易连带出问题的：锁了 max-width 之后别忘 height: auto，只改宽度不改高度，图片会被压扁，看着也像“糊”，但其实是变形。

Computed 面板那条最实用，但有个前提得说清楚：那里读到的 width 是 used value，元素若写了 width: 100% 或被 flex 压缩过，显示的也是最终渲染宽度，反而比 getBoundingClientRect() 更贴近“图片实际按多宽渲染”；只是它同样受父级百分比链影响，看到小数还是得往上翻一层找源头，所以两者是互补而非替代。

rAF 节流补一个执行细节：resize 里要把上一次的 frame 取消掉，也就是先 cancelAnimationFrame(rafId) 再重新 requestAnimationFrame，否则拖窗口时帧回调会排队堆积，卡顿照旧。另外 window.resize 覆盖不到容器自身变化（侧栏折叠、分栏拖拽、弹窗撑开），这类场景用 ResizeObserver 观察图片的父容器更直接，DPR 也顺带在里面读一次就行。

设备模拟那条我完全同意，再补一个同源现象：用 min-resolution: 2dppx 媒体查询写的 2x 背景图规则，在模拟 DPR 下同样会命中并换源，所以那点清晰度提升依旧是“换了图”换来的，和采样算法无关，结论和你一致。

height: auto 再延伸一句：图片放在固定尺寸容器里配 object-fit: cover 时，只写 max-width 基本没用，得给容器定 aspect-ratio 或者给 img 加 object-fit，不然压扁和硬裁切会一起出现。

最后补个比 height: auto 更少人提的坑：max-width: 100% 在 flex 子项里会被 min-width: auto 顶住而失效，得同时写 min-width: 0 才真正生效。

这条把 ResizeObserver 这条线补全了，尤其「观察父容器而不是只盯 window.resize」这个方向我完全认同——侧栏折叠、分栏拖拽这类场景，window.resize 一次都不触发，可图确实被压窄了。

顺着 ResizeObserver 再补一个更准的用法：回调里的 entry.devicePixelContentBoxSize 直接给的是物理像素尺寸，比拿 contentBoxSize 乘 devicePixelRatio 可靠得多——DPR 完全可能是 1.25、1.5 这种非整数，乘法一算就带误差，而它会直接把最终落屏的物理像素报给你，判断 2x 图够不够就看这个值。用的时候 observe(el, { box: 'device-pixel-content-box' })，Safari 支持得晚，包个 try/catch 回退到普通 contentBoxSize 就行。

rAF 那条我倾向更土的办法：记一个 lastWidth，宽度真变了才进 rAF 干活，比每帧 cancel 再 request 更省，也能顺手避开「回调里改尺寸触发 ResizeObserver loop」那个报错——在 RO 回调里同步改被观察元素的尺寸，控制台那行 warning 就是这么来的。

min-width: 0 在 grid 子项上同样成立，写法是 grid-template-columns: minmax(0, 1fr)，不然长图照样把轨道撑开。aspect-ratio 记得给老 Safari 留 padding-top 百分比兜底。

Computed 那条补个操作细节：看到小数就顺着 DOM 往上逐个点父级看 width，找到第一个整数为止，源头基本就在那一层。

结论：devicePixelContentBoxSize 这个方向是对的，但把 lastWidth 当成唯一判断条件会漏掉跨屏时 DPR 变化的情况，建议直接拿物理像素宽度当比较基准。

先说调用细节：observe(el, { box: 'device-pixel-content-box' }) 在不支持的浏览器上是 observe 本身抛 NotSupportedError，所以 try/catch 要包住 observe 这一行，不能只包回调；回退到 contentBoxSize 时注意老实现返回的是数组，取 [0] 再乘 devicePixelRatio，别直接当对象用。

比较基准那条是重点：宽度不变但 DPR 从 1 变 2（拖到 Retina 屏）时，lastWidth 相等就直接 return，后面什么都不会重算。把 entry.devicePixelContentBoxSize[0].inlineSize 存进 lastWidth 就一次解决两个问题——尺寸变了重算，DPR 变了也重算，还省掉额外维护 dpr 变量。rAF 保留，只是进 rAF 之前先过这道比较。

RO loop 那个 warning 本身无害，但 Sentry 这类 SDK 会把它当 JS 错误上报，接监控的话记得加过滤，不然线上噪声很大。grid 再补一条：纵向滚动容器里 min-height: 0 同样得写，minmax(0, 1fr) 只管横向。aspect-ratio 现在支持面够宽了，padding-top 兜底只服务老 Safari，而那个写法要求内容绝对定位，和 object-fit 混用会多出一层定位容器，能不用就不用。

Computed 逐个点父级还是慢，控制台一行 let e=$0;while(e){console.log(e.getBoundingClientRect().width,e);e=e.parentElement} 就能把整条链一次打完。最后提一句：列表页几十张图别一张挂一个 RO，一个观察器 observe 全部元素、回调解构 entries 批量处理，否则观察器自身开销就够呛。