上周帮同事排查一个前端问题：同一个商品的图，在详情页清晰得能看清包装上的小字，切到列表页就糊成一团，边缘发毛、细节发灰，像被人拿橡皮擦蹭过一遍。第一反应是"图片没加载完吧"，强制刷新几次还是那样；又怀疑是压得太狠，把原图下载下来一看，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~3，Retina 屏 Mac 是 2）、CSS 盒子的实际布局尺寸（可能是小数）、以及图片最终落在合成层里的位置（可能是半像素）。这三个参数里任何一个不对，都会直接体现为视觉上的模糊。
1.2 三种"糊"，症状完全不同
把模糊分类是排查效率最高的做法。我在项目里总结成三类，症状和对策完全不一样：
从表现上看，重采样模糊是整张图均匀地软，细节均匀损失，像蒙了一层薄纱，边界还在但没锐度；亚像素模糊是边缘发虚、发毛，图形边缘像是被涂了一道浅灰，甚至会出现左右不对称的"半边糊"，位置固定的元素表现为"整体都糊一点"；压缩模糊则带有明显的块状感或色带，常见于文字和大片渐变区域。
三步就能分开它们：
- 用系统看图工具打开原图，放大到实际显示尺寸对比。原图放大后也糊，说明是资源和缩放倍率问题。
- 把浏览器缩放到 100%，把容器宽高临时改成整数像素（比如 300px 而不是 33.33%）。如果糊感消失，是亚像素问题。
- 打开开发者工具的图层/渲染面板，看图片是否被单独提升成了合成层。如果提升后模糊加重，是合成层降采样问题。
注意：这三步一定要在纯粹的环境里做，别在页面有动画、有
transform在跑的状态下判断，动画会干扰结论。
1.3 三分钟定位法：先确定"锅"在资源还是在渲染
我自己常用一套"三分钟定位法"，不需要任何插件，改几个值就能得出结论。
第一步，把图片的 CSS 宽高临时改成跟原图一样的 CSS 像素数。比如原图 1200×800，DPR 是 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，在 DPR=3 的手机上，需要的物理像素是 360 × 3 = 1080px。如果设计给的是 720px 的图，那实际渲染时浏览器要把 720 拉成 1080，放大 1.5 倍，边界必然发虚。
正确的算法很简单：
所需图片宽度 = CSS 渲染宽度 × DPR在主流机型上我一般这样取值：列表缩略图按 DPR=2 算，主图、Banner 按 DPR=2 到 3 算。注意不是越高越好——DPR=3 的 4K 大图会让首屏加载时间直接翻倍，得不偿失。我的经验做法是：关键视觉（首屏主图、商品大图）按 2x 出，装饰性图片按 1.5x 出，用户头像、图标类按 2x 出并限制最大尺寸。
还有一个更隐蔽的坑：很多设计稿是按 750px 宽（2x）标注的，开发同学直接把标注值当 CSS 像素写，结果等于无意中把 2x 图当 1x 图用，再在高清屏上放大，双重损失。这种问题非常常见，具体表现为"PC 上看着还行，手机上一塌糊涂"。
2.2 srcset 与 sizes：让浏览器自己挑图
光准备多倍图不够，还得告诉浏览器"什么情况下用哪张"。这是srcset和sizes的职责。
<img src="photo-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" width="800" height="600" alt="商品主图" loading="lazy" decoding="async" />这里最容易写错的是sizes。它的含义是"这个图片在页面上的布局宽度是多少"，浏览器会用它乘以 DPR 得到需要的物理像素，再去srcset里挑最接近的一张。sizes写错了，浏览器就挑错图，结果就是糊。
我见过三种典型错误：
sizes直接省略，浏览器默认按100vw算，导致所有图都挑了最大的一张，白浪费带宽。sizes写成了sizes="600px"，但实际布局是50vw，在窄屏下挑了太小的图，糊。- 图片放在 Flex/Grid 容器里，宽度由内容撑开，
sizes根本没法静态描述，最后只能靠ResizeObserver动态改属性。
提示：如果布局宽度真的算不出来，宁可保守一点往大了写。多下一点带宽，比糊图好得多。
2.3 picture 与现代格式：收益和代价要算清楚
picture元素解决的是格式协商问题，不是尺寸问题，但两者经常一起用：
<picture> <source type="image/avif" srcset="photo-800.avif 800w, photo-1600.avif 1600w" sizes="50vw" /> <source type="image/webp" srcset="photo-800.webp 800w, photo-1600.webp 1600w" sizes="50vw" /> <img src="photo-800.jpg" srcset="photo-800.jpg 800w, photo-1600.jpg 1600w" sizes="50vw" width="800" height="600" alt="商品主图" /> </picture>AVIF 和 WebP 在同画质下体积优势很明显，通常能省 30%~60%。但对"糊图问题"来说，这里有一个反直觉的注意点：有损压缩格式的锐度表现不同。同一张图在相同的视觉体积下，WebP 的锐利边缘往往比 JPEG 保持得好，而 AVIF 在低码率下容易出现平滑化的涂抹感。如果你发现换了 AVIF 之后图片"变柔"了，不是 CSS 的问题，是码率给低了，把质量参数从 50 提到 70 试试。
另外一个坑：不要用"生成工具默认参数"批量转格式。我踩过一次，用默认质量批量转了一千多张缩略图，上线后同事反馈"图都糊了"，一查是质量参数被设成了 40。批量处理图片一定要先做 5~10 张样本的目视验收，这一步省不得。
2.4 能矢量就别用位图
图标、简单的几何图形、纯色文字排版、图表线框，这些场景老老实实上 SVG，从根本上不存在缩放宽高导致的糊图问题。我自己的判断标准很粗暴：
| 场景 | 推荐格式 | 理由 |
|---|---|---|
| 图标、Logo | SVG | 任意缩放不失真，体积通常小于 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~82，WebP 用 75~80，AVIF 用 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 class="smart-image" :style="{ aspectRatio: ratio }"> <img :src="fallback" :srcset="srcset" :sizes="sizes" :alt="alt" loading="lazy" decoding="async" /> </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，照样救不回来。所以我把接口契约固定下来：
| 场景 | 返回宽度（单图） | 格式 | 备注 |
|---|---|---|---|
| 列表缩略图 | 400px | WebP + JPEG 兜底 | 按 DPR 2 覆盖 200px 容器 |
| 卡片封面 | 800px | WebP + JPEG 兜底 | 覆盖 400px 容器 |
| 详情主图 | 1600px | WebP + JPEG 兜底 | 覆盖 800px 容器 |
| 用户头像 | 200px | WebP | 上限 200，避免大图浪费 |
| 背景大图 | 1920px | WebP | 桌面端专用 |
后台出图还有两个必须注意的点。第一，缩略图一定要从高质量原图生成，不要从已有的缩略图再生成缩略图。二次压缩的劣化是叠加的，我见过后台为了省事，从 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 78+，WebP 75+，AVIF 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: 375px，left: 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 图基本就解决了。这个"看图在哪儿糊"的直觉，比记任何属性都好用。
