上周帮同事排查一个前端问题同一个商品的图在详情页清晰得能看清包装上的小字切到列表页就糊成一团边缘发毛、细节发灰像被人拿橡皮擦蹭过一遍。第一反应是图片没加载完吧强制刷新几次还是那样又怀疑是压得太狠把原图下载下来一看2400×1600清清楚楚一点问题没有。最后定位到的是一行谁都没想到的 CSS图片容器只有 120px 宽图片挂着width: 100%父级还套了一个transform: scale(1.05)的 hover 动画。就这么三个东西叠在一起一张高清图被硬生生揉成了糊图。这类问题在真实项目里出现频率高得离谱而且特别容易误判——因为绝大多数人第一反应是换张更高清的原图换完之后发现还是糊于是开始怀疑是不是显示器坏了。图片因为 CSS 样式缩放导致变糊本质上是浏览器渲染管线里的一次像素重采样跟图片本身清不清晰是两回事。你要解决它得先搞清楚它在哪一层糊的是资源本身像素不够是缩放算法太粗暴还是元素被放在了半像素位置上。这篇内容我想按定位—资源—CSS—工程化—排查的顺序讲透。前半部分偏原理和判断方法适合刚踩到坑想快速止血的人后半部分是我在项目里沉淀下来的一套出图规范、组件封装和验收清单适合要把这个问题从每次都要查变成再也不会犯的团队。全程都是我实际改过的代码和踩过的坑可以直接抄。1. 先别急着改代码把糊这件事拆开看遇到模糊图最浪费时间的做法就是凭直觉改属性。我见过有人在img上试了七八个属性、换了三版图、加了image-rendering全家桶最后还是糊因为方向从头就是错的。先花几分钟把糊的类型认清楚后面能省下几个小时。1.1 一张图从文件到屏幕中间经历了什么一张图片要在屏幕上显示出来走的是这条链路磁盘上的字节 → 解码成位图像素矩阵→ 按 CSS 盒子的尺寸做重采样 → 交给合成器绘制到物理像素上。模糊只可能发生在后面两步。我习惯用一个特别土的类比来解释给同事听图片文件好比一张印好的印刷品。解码是把它摊开放在桌面上CSS 决定了你给它多大一块展位重采样是把印刷品按展位尺寸放大或缩小复印一份。如果你把一张 A4 印刷品硬塞进名片盒大小的展位复印机就得把内容压到原来的几十分之一笔画自然糊成一片反过来你要把一张邮票铺满一面墙复印机只能靠猜来补像素出来的是马赛克加糊边。关键点在于复印机浏览器不知道你原本画的是什么它只能根据现有的像素猜。所以糊不是 bug是信息量不够或者插值方式不合适的必然结果。链路里还有几个容易被忽略的参数设备的devicePixelRatio下称 DPR物理像素与 CSS 像素的比值手机普遍 2~3Retina 屏 Mac 是 2、CSS 盒子的实际布局尺寸可能是小数、以及图片最终落在合成层里的位置可能是半像素。这三个参数里任何一个不对都会直接体现为视觉上的模糊。1.2 三种糊症状完全不同把模糊分类是排查效率最高的做法。我在项目里总结成三类症状和对策完全不一样从表现上看重采样模糊是整张图均匀地软细节均匀损失像蒙了一层薄纱边界还在但没锐度亚像素模糊是边缘发虚、发毛图形边缘像是被涂了一道浅灰甚至会出现左右不对称的半边糊位置固定的元素表现为整体都糊一点压缩模糊则带有明显的块状感或色带常见于文字和大片渐变区域。三步就能分开它们用系统看图工具打开原图放大到实际显示尺寸对比。原图放大后也糊说明是资源和缩放倍率问题。把浏览器缩放到 100%把容器宽高临时改成整数像素比如 300px 而不是 33.33%。如果糊感消失是亚像素问题。打开开发者工具的图层/渲染面板看图片是否被单独提升成了合成层。如果提升后模糊加重是合成层降采样问题。注意这三步一定要在纯粹的环境里做别在页面有动画、有transform在跑的状态下判断动画会干扰结论。1.3 三分钟定位法先确定锅在资源还是在渲染我自己常用一套三分钟定位法不需要任何插件改几个值就能得出结论。第一步把图片的 CSS 宽高临时改成跟原图一样的 CSS 像素数。比如原图 1200×800DPR 是 1那就写width: 1200px; height: 800px;。清晰了说明是缩放环节的问题还是糊说明原图本身在这个尺寸下就不够。第二步在第一步清晰的前提下把宽度逐步降下来同时观察从哪个比例开始糊。一般来说缩小到原来的 1/2 以内、放大超过 1.5 倍视觉上就开始能感知到质量下降。这个阈值不是绝对标准但足够用来判断我的图尺寸够不够。第三步如果尺寸对了还糊就去查布局元素是否落在半像素上、是否被transform参与过缩放、父级是否有filter或opacity触发了合成。这一步用开发者工具的Computed面板看getBoundingClientRect()的返回值最快只要是小数就值得怀疑。// 在控制台里跑直接看元素的实际渲染位置和尺寸 const el document.querySelector(.target-img); const rect el.getBoundingClientRect(); console.log({ width: rect.width, // 出现 .33 / .5 / .67 这类小数就要留意 height: rect.height, left: rect.left, // left / top 是小数说明元素落在半像素上 top: rect.top, dpr: window.devicePixelRatio, });这段代码我几乎每个项目都会在排查时跑一遍比肉眼猜快得多。尤其是列表页、瀑布流这种由百分比宽度决定尺寸的布局rect.width出现小数的概率非常高。2. 从源头解决让图片资源本身抗缩定位清楚之后第一步永远是资源侧。CSS 再花哨也没法凭空造出像素资源不够一切优化都是徒劳。这一章讲的是怎么把图片资源的尺寸体系搭对这是后面所有 CSS 技巧的前提。2.1 DPR 是最容易被忽略的那个乘数很多人算图片尺寸时只算 CSS 宽度忽略了 DPR。举个真实例子详情页主图容器 CSS 宽度是 360px在 DPR3 的手机上需要的物理像素是 360 × 3 1080px。如果设计给的是 720px 的图那实际渲染时浏览器要把 720 拉成 1080放大 1.5 倍边界必然发虚。正确的算法很简单所需图片宽度 CSS 渲染宽度 × DPR在主流机型上我一般这样取值列表缩略图按 DPR2 算主图、Banner 按 DPR2 到 3 算。注意不是越高越好——DPR3 的 4K 大图会让首屏加载时间直接翻倍得不偿失。我的经验做法是关键视觉首屏主图、商品大图按 2x 出装饰性图片按 1.5x 出用户头像、图标类按 2x 出并限制最大尺寸。还有一个更隐蔽的坑很多设计稿是按 750px 宽2x标注的开发同学直接把标注值当 CSS 像素写结果等于无意中把 2x 图当 1x 图用再在高清屏上放大双重损失。这种问题非常常见具体表现为PC 上看着还行手机上一塌糊涂。2.2 srcset 与 sizes让浏览器自己挑图光准备多倍图不够还得告诉浏览器什么情况下用哪张。这是srcset和sizes的职责。img srcphoto-800.jpg srcset photo-400.jpg 400w, photo-800.jpg 800w, photo-1200.jpg 1200w, photo-1600.jpg 1600w sizes(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 600px width800 height600 alt商品主图 loadinglazy decodingasync /这里最容易写错的是sizes。它的含义是这个图片在页面上的布局宽度是多少浏览器会用它乘以 DPR 得到需要的物理像素再去srcset里挑最接近的一张。sizes写错了浏览器就挑错图结果就是糊。我见过三种典型错误sizes直接省略浏览器默认按100vw算导致所有图都挑了最大的一张白浪费带宽。sizes写成了sizes600px但实际布局是50vw在窄屏下挑了太小的图糊。图片放在 Flex/Grid 容器里宽度由内容撑开sizes根本没法静态描述最后只能靠ResizeObserver动态改属性。提示如果布局宽度真的算不出来宁可保守一点往大了写。多下一点带宽比糊图好得多。2.3 picture 与现代格式收益和代价要算清楚picture元素解决的是格式协商问题不是尺寸问题但两者经常一起用picture source typeimage/avif srcsetphoto-800.avif 800w, photo-1600.avif 1600w sizes50vw / source typeimage/webp srcsetphoto-800.webp 800w, photo-1600.webp 1600w sizes50vw / img srcphoto-800.jpg srcsetphoto-800.jpg 800w, photo-1600.jpg 1600w sizes50vw width800 height600 alt商品主图 / /pictureAVIF 和 WebP 在同画质下体积优势很明显通常能省 30%~60%。但对糊图问题来说这里有一个反直觉的注意点有损压缩格式的锐度表现不同。同一张图在相同的视觉体积下WebP 的锐利边缘往往比 JPEG 保持得好而 AVIF 在低码率下容易出现平滑化的涂抹感。如果你发现换了 AVIF 之后图片变柔了不是 CSS 的问题是码率给低了把质量参数从 50 提到 70 试试。另外一个坑不要用生成工具默认参数批量转格式。我踩过一次用默认质量批量转了一千多张缩略图上线后同事反馈图都糊了一查是质量参数被设成了 40。批量处理图片一定要先做 5~10 张样本的目视验收这一步省不得。2.4 能矢量就别用位图图标、简单的几何图形、纯色文字排版、图表线框这些场景老老实实上 SVG从根本上不存在缩放宽高导致的糊图问题。我自己的判断标准很粗暴场景推荐格式理由图标、LogoSVG任意缩放不失真体积通常小于 PNG简单插画、线稿SVG放大到 Banner 尺寸也不糊产品照片、实拍图JPEG / WebP / AVIF位图更合适SVG 会导致体积爆炸截图、带文字的图PNG 或高质量 WebP文字边缘对压缩非常敏感渐变背景、装饰形状CSS 渐变 / SVG不用出图省一次请求有个细节要提醒SVG 内嵌了位图时缩放一样会糊。我见过把 JPEG 塞进 SVG 再当矢量图用的操作那是自欺欺人。另外 SVG 如果设置了固定的width/height属性但没有viewBox缩放时表现会非常诡异一定要带上viewBox。2.5 位图放大有极限超过就换方案必须承认位图放大是有物理上限的。经验值是这样放大 1.2 倍以内基本看不出问题1.5 倍开始有感知2 倍以上就明显糊3 倍以上基本不能看。如果你确实需要把一张小图铺满大容器比如用户上传的头像要显示在个人主页大背景上有三条路第一换更大尺寸的原图。这是最直接的前提是你手里有。第二用 CSS 做视觉补偿加一点点轻微的高斯模糊 提升对比度让糊看起来像柔光处理而不是质量事故。这招在背景类大图上效果不错.hero-bg { background-image: url(user-avatar.jpg); background-size: cover; background-position: center; /* 让放大后的软看起来像刻意设计的柔焦 */ filter: blur(0.3px) contrast(1.05) saturate(1.05); transform: scale(1.02); /* 轻微放大把不干净的边缘推出可视区 */ }第三改变设计。用纯色、渐变或者模糊色块做底把小图放在上面当点缀。这是最省事也最不容易出错的做法。心得transform: scale()配合filter: blur()做背景柔化时scale值别超过 1.05超过之后细节损失会盖过柔化带来的收益反而更难看。3. CSS 写法层面的关键细节资源到位之后剩下的问题基本都在 CSS 里。这一章是我实际调过的属性、写法和它们的适用边界每条都对应过具体案例。3.1 width/height 与 max-width 的经典组合最稳的一套写法其实很朴素.img-responsive { display: block; width: 100%; max-width: 100%; height: auto; /* 关键防止图片被拉伸到超出自身像素密度后发虚 */ image-rendering: auto; }height: auto配合width: 100%保证等比缩放不会变形。display: block是为了消除img默认的基线间隙那个间隙会让父容器高度多出 3~4px容易引发半像素问题。max-width: 100%是很多老项目的万能修复但它有个副作用在容器比图片大时它不生效图片保持原始尺寸。如果原始尺寸是奇数且容器又是居中定位很容易落到半像素上。所以我更倾向于用width: 100%明确指定。还有一个很多人不知道的点在img上显式写上width和height属性HTML 属性不是 CSS。现代浏览器会据此自动计算aspect-ratio在图片加载前就把位置占好避免加载完成后布局跳动。布局跳动本身不导致模糊但它会让图片在动画/重排过程中被临时以错误尺寸渲染视觉上就是加载完成后抖一下然后变糊。3.2 object-fit裁切代替拉伸容器宽高比和图片宽高比不一致时object-fit是救命属性取值行为适用场景糊图风险fill强行拉伸填满几乎不用极高直接变形糊contain等比缩放完整显示需要看全整张图中留白多时图偏小cover等比缩放裁切填满卡片封面、头像低但会裁掉边缘none保持原始尺寸特殊需求低我用得最多的是cover.card-cover { width: 100%; aspect-ratio: 4 / 3; object-fit: cover; object-position: center; }fill是新手里最高频的坑。它的语义是拉满宽高比不一致时图像会被非等比拉伸横竖方向插值比例不同糊得特别难看。看到图糊而且人物被拉胖了基本就是fill。object-position也要留意默认是center如果设置成百分比小数比如object-position: 33.3% 66.6%裁切位置会落在非整数像素上虽然影响比元素偏移小但在小尺寸元素上依然可见。3.3 image-rendering用对了是救星用错了是灾难image-rendering是唯一能直接干预缩放插值算法的 CSS 属性但它被严重滥用了。/* 像素画、复古风游戏素材专用 */ .pixel-art { image-rendering: pixelated; image-rendering: crisp-edges; /* 兼容写法Firefox 支持更好 */ } /* 普通照片不要加 */ .normal-photo { image-rendering: auto; /* 保持默认的双线性/三线性插值 */ }要理解它的能力边界image-rendering只能改变怎么猜像素不能创造像素。pixelated用的是最近邻采样放大后每个像素变成规整的方块边缘锐利但锯齿严重——这对像素画是正确的对照片是毁灭性的会让人脸变成色块拼图。crisp-edges的兼容性比较微妙各浏览器实现不一致现在的规范里它和pixelated的行为在某些引擎下趋同。所以我的建议是只有当你明确在处理像素艺术、扫描件需要锐化边界、或者 1px 线条图案时才动这个属性。普通照片永远保持auto。网上流传的-webkit-optimize-contrast属于历史遗留写法现在基本没有实际效果别再往代码里加了。3.4 背景图background-size 的隐藏成本背景图和img走的渲染路径不完全一样坑也更集中。.banner { width: 100%; height: 320px; background-image: url(banner.jpg); background-size: cover; /* 等比缩放填满裁切溢出 */ background-position: center center; background-repeat: no-repeat; }background-size: cover在窄容器里会放大背景图如果背景图本身只有 750px 宽容器在桌面端被拉到 1920px那就是 2.5 倍放大必糊。这个问题的正确解法是用媒体查询切换不同尺寸的背景图.banner { background-image: url(banner-750.jpg); background-size: cover; background-position: center; } media (min-width: 768px) { .banner { background-image: url(banner-1200.jpg); } } media (min-width: 1400px) { .banner { background-image: url(banner-1920.jpg); } }不要用image-set()来偷懒——它的浏览器支持虽然改善了不少但在背景图场景下和srcset的协商逻辑还是有差异跨端表现不一致我没在正式项目里用过。另一个细节背景图加background-attachment: fixed在移动端会触发全屏重绘既卡又容易糊移动端不要用。3.5 transform 缩放和尺寸缩放渲染路径不一样这是个容易被忽略但很关键的区别。用width改尺寸浏览器在布局阶段就按新尺寸做一次重采样然后按 1:1 绘制质量由图片像素和插值算法决定。用transform: scale()缩放元素可能在栅格化之后被合成器直接放大。如果元素被提升成了独立合成层浏览器会先按原尺寸把它栅格化成一个纹理再对这个纹理做缩放这个二次缩放的质量通常比直接按目标尺寸渲染差因为纹理的原始分辨率是按 1x 或按当时 DPR 定的。这就解释了为什么很多 hover 放大动画一执行图片就变糊/* 有风险的写法 */ .card:hover .thumb { transform: scale(1.15); transition: transform 0.3s; }图被栅格化一次再放大 1.15 倍这个放大是纹理级的插值比 CSS 尺寸缩放更容易糊。我现在的做法是两选一方案 A如果图片本身够大加一个will-change让浏览器提前按更大尺寸栅格化。但will-change是双刃剑滥用会导致显存暴涨我一般只在同时不超过 3 个元素的场景下用。.card:hover .thumb { will-change: transform; transform: scale(1.15); }方案 B用容器 overflow: hidden 图片自身transform同时保证图片的原图尺寸至少是显示尺寸的 1.5 倍这样即使纹理放大损失也在可接受范围内。.card { overflow: hidden; border-radius: 8px; } .card .thumb { width: 100%; display: block; transform: scale(1); transition: transform 0.35s ease; /* 关键图片原图分辨率按 1.5x 出 */ } .card:hover .thumb { transform: scale(1.08); }3.6 半像素与小数尺寸最隐蔽的模糊来源这一类问题最难查因为代码看起来完全正确就是糊。浏览器绘制时元素的最终位置会被映射到物理像素网格。如果元素左边缘落在物理像素的 0.5 位置浏览器就必须用抗锯齿或者插值把这个边界摊到两个像素上结果就是边缘发虚。图片元素尤其明显因为整张图都要参与这次插值。三个最常见的触发条件容器宽度用了33.33%、20%这类除不尽的百分比在特定视口宽度下产生小数布局尺寸。使用transform: translate(-50%, -50%)做居中元素尺寸又是奇数。图片本身宽高是奇数容器却按偶数居中。/* 危险在 1280px 视口下宽度是 426.66px */ .grid-item { width: 33.33%; } /* 更稳用网格定义列数让浏览器自己算 */ .grid { display: grid; grid-template-columns: repeat(3, 1fr); gap: 16px; }如果在某些场景下必须用百分比可以试试给图片父级加一点点取整处理.grid-item { width: 33.33%; /* 让内部图片贴合整数像素边界 */ } .grid-item img { width: 100%; display: block; /* 兜底方案轻微上采样掩盖半像素模糊 */ transform: translateZ(0); }transform: translateZ(0)会强制元素进入合成层合成器对整数像素边界的处理通常比主线程布局更规整某些情况下确实能改善模糊。但它不是万能药在某些设备上反而会加重模糊所以一定要在真机上验证不能只看桌面浏览器。排查工具推荐开发者工具的Rendering面板里打开 Layer borders 和 Paint flashing能直观看到元素边界落在哪里、哪些区域在重绘。3.7 aspect-ratio 占位别让布局抖动再毁一遍图aspect-ratio现在是标配了它的价值不只是防布局抖动也间接防了模糊如果图片没有预留空间加载完成前容器高度是 0加载后高度突变成实际值这个过程里如果同时有其他动画在跑图片可能被以错误尺寸渲染一帧然后重新渲染视觉上会有一次闪动。.thumb-box { width: 100%; aspect-ratio: 16 / 9; overflow: hidden; background: #f5f5f5; /* 占位底色避免白闪 */ } .thumb-box img { width: 100%; height: 100%; object-fit: cover; display: block; }aspect-ratio的值尽量写成整数比16 / 9、4 / 3、1 / 1不要写1.7777这种小数避免浏览器算出小数高度。老项目如果没有aspect-ratio支持用padding-top: 56.25%的老办法也能达到同样效果但同样要小心百分比带来的小数高度。4. 工程化落地把规范固化进流程上面这些东西掌握之后解决单个问题很快。但真实项目里有几百上千张图靠人一张张查是不现实的。这一章讲怎么把它变成流程的一部分。4.1 构建期图片流水线定尺寸矩阵和命名我项目里的约定是这样的每张图在进入代码仓库前必须由构建脚本生成确定的尺寸档位命名带宽度后缀方便srcset直接拼。# 用 sharp-cli 批量生成多档尺寸Node 环境 npx sharp-cli -i src/assets/products/*.{jpg,png} \ -o build/images \ resize 400 --withoutEnlargement npx sharp-cli -i src/assets/products/*.{jpg,png} \ -o build/images \ resize 800 --withoutEnlargement npx sharp-cli -i src/assets/products/*.{jpg,png} \ -o build/images \ resize 1600 --withoutEnlargement--withoutEnlargement这个参数必须加。它的作用是只缩小不放大避免把小图强行拉大生成一堆假高清图——那种图体积更大、看着更糊纯属自欺欺人。命名约定我固定用{name}-{width}.{ext}比如product-800.webp。这样组件里可以直接根据名字拼出srcset不用维护一张映射表。至于质量参数我的经验值是JPEG 用 78~82WebP 用 75~80AVIF 用 60~70。低于这个区间就容易出现肉眼可见的块状和涂抹。同一个参数在不同内容上表现差别很大纯色背景的产品图可以压得更狠纹理复杂的实拍图就得往上抬。所以我会挑几张最有代表性的图做基准样本参数定完之后定期回归看一次。4.2 组件封装一个自动带 srcset 的图片组件手写srcset一多必然出错封装成组件是最好的办法。下面是我在 Vue 3 项目里用的版本思路在 React 里一样能套。!-- components/SmartImage.vue -- script setup import { computed, ref, onMounted, onBeforeUnmount } from vue; const props defineProps({ name: { type: String, required: true }, // 不含尺寸后缀的文件名如 product-01 ext: { type: String, default: webp }, sizes: { type: String, default: 100vw }, // 布局宽度描述 widths: { type: Array, default: () [400, 800, 1600] }, alt: { type: String, default: }, ratio: { type: String, default: 4 / 3 }, }); const srcset computed(() props.widths.map((w) /images/${props.name}-${w}.${props.ext} ${w}w).join(, ) ); const fallback computed(() /images/${props.name}-800.jpg); /script template div classsmart-image :style{ aspectRatio: ratio } img :srcfallback :srcsetsrcset :sizessizes :altalt loadinglazy decodingasync / /div /template style scoped .smart-image { width: 100%; overflow: hidden; background: #f5f5f5; } .smart-image img { width: 100%; height: 100%; object-fit: cover; display: block; /* 防止奇数尺寸落在半像素上 */ transform: translateZ(0); } /style关键在于sizes必须由使用方传入准确值。列表页传(max-width: 600px) 50vw, 300px详情页传(max-width: 600px) 100vw, 600px。这一步如果偷懒不传前面的努力全白费。还有一个我在踩坑之后加的机制在开发环境下检测漏传sizes的情况控制台打警告。因为漏传的后果太隐蔽了图片能显示只是悄悄糊了不专门盯着根本发现不了。4.3 后台出图和设计侧规范要对齐前端把 CSS 抠到极致如果后台接口返回的图宽只有 200px照样救不回来。所以我把接口契约固定下来场景返回宽度单图格式备注列表缩略图400pxWebP JPEG 兜底按 DPR 2 覆盖 200px 容器卡片封面800pxWebP JPEG 兜底覆盖 400px 容器详情主图1600pxWebP JPEG 兜底覆盖 800px 容器用户头像200pxWebP上限 200避免大图浪费背景大图1920pxWebP桌面端专用后台出图还有两个必须注意的点。第一缩略图一定要从高质量原图生成不要从已有的缩略图再生成缩略图。二次压缩的劣化是叠加的我见过后台为了省事从 400px 图生成 200px 图结果 200px 那张糊得不能用。第二如果后台用的是图像处理库比如 PHP 的 GD 或 Imagick一定要把插值方式设成高质量模式GD 默认的IMG_BICUBIC比IMAGICK的LANCZOS差不少条件允许就用 Imagick。// 用 Imagick 生成高质量缩略图重点是 filter 设置 $img new Imagick($sourcePath); $img-setImageFormat(webp); $img-setImageCompressionQuality(80); // Lanczos 是缩小场景下质量最好的重采样滤镜 $img-resizeImage(800, 0, Imagick::FILTER_LANCZOS, 1.0, true); $img-writeImage($targetPath);resizeImage的第四个参数是模糊因子缩小场景用 1.0如果要做锐化补偿缩小之后要显式调一次unsharpMask因为降采样本身会让图像变软。4.4 验收和自动化检查规范定完还得有办法验证它被遵守了。我做过的三件小事效果都挺好的第一写一个 Node.js 脚本扫描源码里的img标签凡是缺少srcset或者sizes的直接让 CI 失败。粗暴但极其有效。第二维护一个视觉回归页面把所有典型图片场景列表、详情、卡片、头像、背景大图集中在一个页面里每次图片相关的改动都在真机上过一遍。桌面浏览器模拟的 DPR 和真机差异很大必须上真机。第三把 DPR 1 / 2 / 3 三档的截图作为基准存下来改动前后做像素级 diff。这一招抓出过好几次看起来没改其实改了的问题。5. 常见问题速查与避坑记录最后这一章是纯经验输出。前面讲的是应该怎么做这里讲的是我实际怎么做错的以及后来怎么查出来的。5.1 问题排查速查表现象大概率原因快速验证方法解决方向整张图均匀发软、发灰资源像素不够被放大了把容器尺寸临时改成原图尺寸出更大尺寸的图或按 DPR 补 2x高清屏上糊普通屏正常只有 1x 图缺 srcset改成 2x 图后清晰补多倍图 srcset边缘发毛图中间还行半像素/小数尺寸控制台看 getBoundingClientRect用 grid 替代百分比整数尺寸hover 或动画时糊停下就清晰transform 缩放纹理级插值去掉 transform 再看提前栅格化或加大原图背景图在桌面端糊background-size: cover 放大检查背景图实际宽度媒体查询切换大尺寸背景图换 WebP/AVIF 后变柔压缩质量参数太低提质量重压对比JPEG 78WebP 75AVIF 60图被拉胖且糊object-fit: fill检查 object-fit 取值改成 cover 或 contain图在列表页糊详情页清晰不同容器尺寸用了同一张图对比两个页面的容器宽度列表页单独出一档小图尺寸加载完成后闪一下然后糊布局抖动导致重渲染打开 Painting flashing 观察显式写 width/height 或 aspect-ratio移动端糊桌面端正常DPR 未计入看 devicePixelRatio按 DPR 2~3 出图5.2 我踩过的几个坑坑一以为image-rendering: crisp-edges是万能锐化。早期我在一个电商项目里给所有商品图加了这个本意是让图更清楚结果上线后被吐槽图看着像被描过边特别是带渐变的图出现了明显的色阶断层。后来才明白它改变的是插值算法对于本来就不缺像素的图只会破坏原有的平滑过渡。坑二忽略了transform: translate(-50%, -50%)的半像素问题。有个弹窗里的图片一直糊尺寸、格式、DPR 全查了一遍没问题最后发现弹窗容器是width: 375pxleft: 50%加translateX(-50%)在 750px 视口下计算出来正好落在 .5 像素上。改成left: calc(50% - 187px)之后立刻清晰。这种问题的杀伤力在于它只在你某个特定屏幕宽度下出现换个分辨率就好了极易被判定成偶发问题。坑三拿缩略图当原图二次生成。后台的数据迁移脚本为了省时间直接从已有的 400px 缩略图生成了 800px 的大图接口返回给前端的是一张被放大过的图前端这边还以为是 CSS 的问题查了两天。后来我在后台加了一条校验生成目标图时如果目标宽度大于源图宽度直接报错不允许放大。坑四will-change加太多反而更糊。我有一次给列表里所有卡片的图片都加了will-change: transform想着提升 hover 动画性能结果是显存占用暴涨滚动时反而掉帧而且部分设备上因为图层太多被引擎降级处理图片看着更软。后来改成只在 hover 的那一刻动态添加、离开时移除问题才解决。坑五文档类项目里的图片路径错位。这个和 CSS 没直接关系但结果很像糊图。在 Markdown 笔记里我经常同时存在引用原图和引用压缩图两套文件路径规则没统一结果某些页面引用了压缩版。表现就是这篇笔记的图很清楚那篇就糊。后来我固定了一套规则原图放assets/origin/压缩图放assets/compressed/引用永远只指向压缩图目录靠构建脚本生成不再手工维护两套。5.3 特殊场景canvas、缩放组件和跨端除了普通img还有几个场景值得单独提一下。Canvas 与图片导出。用 canvas 把图片画出来再导出时如果 canvas 的width/height属性还是默认的 300×150而 CSS 把它显示成 800×400那画出来的内容就是被放大的。正确做法是把 canvas 的width/height按 DPR 放大function setupCanvas(canvas, cssWidth, cssHeight) { const dpr window.devicePixelRatio || 1; canvas.width Math.round(cssWidth * dpr); canvas.height Math.round(cssHeight * dpr); canvas.style.width cssWidth px; canvas.style.height cssHeight px; const ctx canvas.getContext(2d); ctx.scale(dpr, dpr); // 让后续绘制按 CSS 像素坐标走 return ctx; }这个套路在需要保证导出图清晰的场景里必须用忘了ctx.scale(dpr, dpr)就会出现显示清楚但导出的文件模糊的诡异现象。轮播与多图容器。轮播组件里图片数量和容器宽度经常是动态的sizes没法静态写死。我一般给轮播组件加一个ResizeObserver在尺寸变化时动态更新图片的sizes属性。同时在配置项里限制一次最多展示几张图——单屏图片越多每张的布局宽度越小sizes算错的概率越大。桌面端控件的缩放。如果你在做桌面端界面比如 Qt 这类框架会遇到非常类似的场景控件自适应缩放时图像发虚。原因基本一致——按逻辑尺寸渲染后整体缩放。解决思路也一样要么在缩放后重新按目标尺寸加载资源要么把高分辨率资源和显示尺寸解耦。跨端项目里把图片尺寸策略做成一个共享的配置比在每个端各写一套要省心得多。带文字的截图和大图。这类内容对模糊最敏感。文字边缘只要有一点点插值就会出现灰边看着就是糊。我的处理原则是带文字的图尽量保持 1:1 显示不做任何缩放如果必须缩放缩小时用整数倍1/2、1/4放大时干脆重出图。5.4 我现在的默认操作顺序最后把我现在遇到这类问题时的固定流程记下来直接照着走基本不会跑偏打开原图确认它的像素尺寸算一下显示尺寸 × DPR是多少。在控制台跑一遍getBoundingClientRect()看宽高和位置有没有小数。临时把图片尺寸改成整数且等于期望值看是否变清晰判断问题层级。检查object-fit、transform、filter、will-change是否有异常参与。检查资源侧有没有多倍图、srcset、sizes是否写对。真机验证桌面浏览器的模拟 DPR 结论经常不准。改完之后把这条经验补进速查表别让下一个人再查一遍。说个我自己最常用的判断习惯如果一张图在详情页清晰、列表页糊那九成不是资源问题而是两张图用了不同尺寸或者不同容器宽度。这时候别急着换图先去比对两个页面的sizes和容器宽度往往五分钟就能定位。反过来如果同一张图在同一个位置PC 上清晰、手机上糊那八成是 DPR 没算进去补一档 2x 图基本就解决了。这个看图在哪儿糊的直觉比记任何属性都好用。