设计稿里的图片明明很清晰，为什么到了手机上却糊了？一文讲透 DPR、压缩与格式选择

前端选图看起来只是决定下载 PNG、JPG 、SVG还是 WebP，真正使用时却会遇到一连串问题：

1. 为什么 360 CSS px 宽的页面要准备 720 px 图片？

2. 为什么四倍图放在二倍屏上通常不会更清楚？

3. PNG 明明使用无损编码，压缩后为什么还会出现色带和颗粒？

4. 同一个 Logo 为什么用 SVG 放大不糊，用低分辨率 PNG 却可能发虚？

这些问题表面上各不相同，其实都围绕一条主线：图片文件带来了多少信息，编码和压缩保留了多少信息，浏览器又怎样把这些信息显示到屏幕上。

这不只是一篇比较后缀的选型表。我们会从一张 360 CSS px 的 Banner 出发，依次讲清图片像素、CSS 像素、物理像素、DPR、色深、颜色量化、编码解码、透明度和矢量图，最后再回到 JPG、PNG、WebP、AVIF、SVG、PDF 的实际选择。

读完以后，你应该能够回答三个问题：

1. 一张位图需要准备多少像素，才能在目标屏幕上清楚显示？
2. 图片压缩删掉了什么信息，色带和抖动颗粒又是怎样产生的？
3. 面对照片、UI、Logo 或整页文档，应该选择哪种格式，为什么？

如果现在只想先拿走选型结论，可以记住：

照片和 Banner 优先评估 WebP 或 AVIF，并准备 JPG 回退；透明截图和 UI 素材优先 PNG，也可以评估 WebP/AVIF；图标和 Logo 优先 SVG；需要保留整页排版、交付或打印时使用 PDF。

但这只是默认方向。真正落地时，还要继续确认三件事：

1. 这是照片、透明 UI、图标，还是一整页文档？
2. 页面实际显示多大，目标屏幕 DPR 是多少？
3. 目标浏览器、App 或交付方能不能正确打开？

图 1：先拆开一张位图：它本质上是像素，再由颜色通道和可选的透明度组成。

一、先从手机屏幕看：为什么 360 的页面要用 720 的图片

这里先记住结论：

页面看起来宽 360 CSS px，不代表屏幕横向只有 360 个发光点；在 DPR 为 2 的二倍屏上，它对应 720 个横向物理像素。

图 2：二倍屏的"二倍"表示横向和纵向都变成 2 倍，因此 360 CSS px 宽的页面会由 720 个横向物理像素显示。

接下来，我们从前端最常见的手机页面开始拆解。

假设一台手机的页面可视宽度是 360 CSS px。这里的 360 是前端布局使用的逻辑宽度，不代表屏幕横向真的只有 360 个发光的小格子。页面里有一张铺满宽度的 Banner，它的显示宽度同样是 360 CSS px。

这台手机的 DPR 为 2，前端通常把它叫作"二倍屏"。DPR 是 Device Pixel Ratio，中文叫"设备像素比"。DPR 为 2，表示 1 个 CSS 像素在横向和纵向上都要由 2 个物理像素显示，也就是占用 2×2 个物理像素。

因此，一个宽 360 CSS px 的页面，在这块二倍屏上会使用 360 × 2 = 720 个横向物理像素。Banner 要铺满页面，也要填满这 720 个物理像素。

这里的物理像素，可以先理解成屏幕上一个个能够独立显示颜色的"发光小格子"。所以这句话也可以说得更直白：页面看起来宽 360 CSS px，但二倍屏横向实际上有 720 个发光小格子参与显示。

严格来说，一个物理像素内部通常还会由红、绿、蓝等子像素组成。不过这是更细一层的结构，暂时不影响我们理解 DPR。

现在再看图片。既然屏幕横向有 720 个位置需要颜色，Banner 最好也能提供至少 720 个横向图片像素。所以我们准备一张宽 720 图片像素的二倍图，再让它以 360 CSS px 的宽度显示。

这里说的"显示成 360 CSS px"，只是规定图片在页面上占多宽，并不是先把图片丢掉一半像素，变成一张 360 px 的图片。浏览器最终仍然要把它绘制到 720 个横向物理像素上。图片提供 720 个横向像素，屏幕也需要 720 个横向像素，两边在像素数量上刚好够用，不需要浏览器凭空补细节。

到这里，再给四个概念贴标签就容易了：

• 图片像素：图片文件自己带来的"小格子"；
• CSS 像素：前端用来规定页面尺寸的单位；
• 物理像素：屏幕上真正发光的"小格子"；
• DPR：CSS 像素和物理像素之间的换算比例，DPR 为 2 也常叫"二倍屏"。

如果以 360 CSS px 为设计和开发基准，那么宽 360 px 的图片通常叫 1 倍图，宽 720 px 的图片通常叫 2 倍图。在二倍屏上显示 360 CSS px 宽的 Banner，使用 720 px 的二倍图，像素数量正好匹配。

至于分辨率、色深、透明度和文件格式，它们都在描述图片文件本身：

• 分辨率（像素尺寸）：图片横向和纵向各有多少图片像素；
• 色深：每个图片像素能记录多少颜色等级；
• 透明度：每个图片像素能透过去多少；
• 文件格式：这些信息用什么规则保存和压缩。

这里先记住一句话：

图片像素负责"带来多少信息"，CSS 像素负责"显示多大"，物理像素负责"真正显示"，DPR 负责在后两者之间换算。

接下来我们继续沿用这张 Banner，看看图片像素不够时，为什么画面会发虚。

1. 三种像素和 DPR：为什么 1 倍图在二倍屏上会发虚

上面的例子使用了宽 720 px 的二倍图，像素数量刚好够用。现在保持 Banner 的显示宽度不变，把图片换成宽 360 px 的一倍图：

• 360 CSS px：Banner 在页面上的显示宽度；
• 720 物理像素：二倍屏横向真正用来显示 Banner 的小格子；
• 360 图片像素：一倍图能够提供的横向颜色信息。

问题来了：二倍屏需要用 720 个横向物理像素显示这张 Banner，1 倍图却只提供了 360 个横向图片像素。浏览器必须把 360 个图片像素重新映射到 720 个物理像素上。这个过程就是放大，也叫上采样。

横向看，1 个图片像素大约要覆盖 2 个物理像素；横向和纵向一起看，关系是这样的：

1×1 个图片像素 → 放大 → 2×2 个物理像素

浏览器怎样完成放大？它可以直接复制原来的颜色，也可以参考周围图片像素，为目标物理像素计算一个过渡颜色，这种计算叫插值。因此，放大是整个过程，复制或插值是完成放大的方法。

无论使用哪种方法，原图仍然只有 360 个横向图片像素，没有增加新的真实细节。直接复制容易看到方块和锯齿；插值能让边缘平滑一些，但文字和细线可能发虚。

避免这种问题，可以直接计算：

图片像素宽度 ≥ CSS 显示宽度 × DPR

这张 Banner 显示宽度为 360 CSS px，屏幕 DPR 为 2，所以图片至少需要 360 × 2 = 720 px。一张 720 px 的 2 倍图，刚好可以让一个横向图片像素对应一个横向物理像素。

设计师有两种常见做法，结果一样：

• 设计稿按 360 px 制作，导出 2 倍图，得到 720 px；
• 设计稿按 720 px 制作，页面仍按 360 CSS px 开发，导出 1 倍图，也得到 720 px。

第二种做法有一个前提：720 px 设计稿里的尺寸整体都是 360 px 基准的 2 倍，开发时也会把标注尺寸除以 2。不能只看到"720"这个数字，就直接把它叫作 2 倍图。

再比较 2 倍图和 4 倍图。以 360 CSS px 为例，2 倍图是 720 px，4 倍图是 1440 px。

在 DPR 为 2 的屏幕上，Banner 最终只使用 720 个横向物理像素：

2 倍图：720 图片像素  → 720 物理像素
4 倍图：1440 图片像素 → 缩小到 720 物理像素

这里的"缩小"到底发生了什么？我们只看 1 个 CSS 像素区域：

4 倍图提供：4×4 个图片像素
DPR 2 屏幕只有：2×2 个物理像素

也就是每 2×2 个图片像素，大约合成 1 个物理像素

浏览器会根据这 4 个图片像素的颜色，计算出一个更适合当前物理像素的颜色。这个过程叫重采样。它不是把 4 份细节完整塞进 1 个点里，而是对信息进行筛选和合并。多出来的细节仍会被舍弃，但原图的信息足够，不需要浏览器凭空补细节。

所以在 DPR 为 2 的屏幕上，4 倍图和 2 倍图的细节上限基本相同。4 倍图经过缩小后，斜线等边缘有时会稍微平滑，但通常不会明显更清楚，只会增加下载体积。

这就是两者的核心区别：

缩小是"信息多，筛选并合并"；放大是"信息少，估算并补齐"。

图 3：1 倍图需要估算补齐，2 倍图刚好一一对应，4 倍图会重采样合并，因此通常不会比 2 倍图明显更清楚。

换到 DPR 为 4 的屏幕，Banner 需要 360 × 4 = 1440 个横向物理像素。4 倍图正好够用；2 倍图只有 720 px，需要被放大到 1440 px。因此，在 DPR 为 4 的屏幕上，4 倍图通常比 2 倍图更清楚。

同样的公式也适用于小图标。图标显示宽度为 24 CSS px，屏幕 DPR 为 2，准备宽 48 px 的图片通常就够了。

最后记住两条判断：

图片像素尺寸 ≥ CSS 显示尺寸 × DPR：像素数量够用
图片像素尺寸 < CSS 显示尺寸 × DPR：图片需要放大，可能发糊

这里说的只是"像素数量够不够"。原图本身模糊或压缩严重，尺寸达标也不会自动变清楚。

在格式、画面内容和压缩参数相近时，2 倍图的宽和高都扩大 2 倍，总像素会变成 4 倍，文件通常也会更大。前端要在清晰度和下载体积之间取平衡。

2. 色深与颜色量化：为什么颜色少了会出现色带

这一节最容易混淆两句话：

• "每个通道是 8 bit"；
• "整张图片被压成 256 色"。

它们都有数字 256，但说的不是同一件事。我们先把它们拆开。

先记住结论：每通道 8 bit 表示 R、G、B 各自都有 256 个等级；整张图 256 色表示所有像素共用最多 256 种代表色。

图 4：每通道 8 bit 是 R、G、B 各有 256 个等级；整张图 256 色则是所有像素共用最多 256 种代表色。

2.1 每通道 8 bit：每一种基础颜色都有 256 个等级

最常见的 RGB 图片，可以理解成三个颜色通道：

• R：红色；
• G：绿色；
• B：蓝色。

这里的 bit 可以理解成只能表示 0 或 1 的小开关。1 个 bit 有 2 种状态，8 个 bit 就有 2⁸ = 256 种组合，因此一个 8 bit 通道可以记录 0～255 共 256 个等级。

日常所说的"8 bit 图片"，通常表示每个通道都有 8 bit：R、G、B 都能从 0～255 独立取值。例如：

• R=255、G=0、B=0：纯红；
• R=0、G=255、B=0：纯绿；
• R=0、G=0、B=255：纯蓝；
• R=255、G=255、B=255：白色；
• R=0、G=0、B=0：黑色。

三个通道组合后，一个像素理论上可以从 256 × 256 × 256，也就是大约 1677 万种颜色中选择一种。因此，常见的 8 bit RGB 也叫 24 bit RGB：红、绿、蓝三个通道各占 8 bit，合起来是 8 + 8 + 8 = 24 bit。

这里的 255 只是单个通道的最大值，不是所有通道加起来的最大值；24 bit 也不是只有 24 种颜色。

专业图像里常说的"16 bit"，通常是指每个通道 16 bit 。这时一个通道有 2¹⁶ = 65536 个等级，取值范围是 0～65535。更多等级主要是给摄影后期、HDR 和高质量印刷留出更大的调色空间，减少反复调整后出现色带的风险；日常 Web 图片仍以每通道 8 bit 为主，因为体积、兼容性和显示需求通常更合适。

2.2 整张图压成 256 色：全图共用一个小调色板

"整张图片压成 256 色"是另一回事。它不是让 R、G、B 每个通道都保留 256 个等级，而是让整张图片最多只能使用 256 种代表色。

图 5：调色板颜色可以被任意像素重复使用，但每个像素只能选择其中一种，不能把几种颜色重新组合成新颜色。

可以把它想成画画：原来你面前有约 1677 万种颜料可以选，现在只给你一个装有 256 种颜料的小盒子。压缩工具会先观察整张图片，挑出一组比较有代表性的颜色，组成一张调色板。之后，每个像素不再直接保存完整的 R、G、B，而是记录"我使用调色板里的第几号颜色"。

压成 256 色后，整张图片只有 0～255 共 256 个调色板编号。量化工具会从原图众多颜色中选出最多 256 种代表色，每个编号只保存其中一种。例如：

0 号：深蓝
1 号：浅蓝
2 号：绿色
3 号：棕色
......

调色板一旦建立，0～255 中的每个编号就对应一种固定的代表色。同一个编号可以被任意多个像素重复使用，但一个像素只能选择一个编号，不能选择"1 号 + 2 号"，再把两种颜色混成一种新的真实颜色。要加入一种新颜色，就必须再占用一个调色板编号。

真正的限制是：**整张图片最多只能保留 256 种不同的代表色。**没有进入调色板的原始颜色必须换成相近的代表色；这种替换为什么可能形成色带，我们放到 2.5 节再详细解释。

那么，这 256 种代表色是怎样选出来的？这个过程叫颜色量化。我们先看完整流程。

图 6：颜色量化通常先统计并分组相近颜色，再选择代表色、组成全图调色板，最后把每个像素映射到接近的代表色。

不同工具的算法并不完全相同，但可以先把典型流程理解成下面五步：

1. 统计整张原图中出现的颜色；
2. 把比较相近的颜色分到一组；
3. 从每组中选择一种能代表这组颜色的颜色；
4. 用这些代表色组成整张图片共用的调色板；
5. 把每个原始像素映射到比较接近的代表色。

工具通常会综合考虑颜色出现频率、颜色之间的距离以及替换后产生的视觉误差，而不是给天空、树木和人物平均分配固定名额。大面积或经常出现的颜色可能获得更多代表色，少量颜色可能被合并；不同算法和参数得到的调色板也可能不同。

代表色怎样选择，会直接影响压缩结果。某个区域能够使用的相近代表色越少，原始颜色被合并得越多；具体为什么会形成色带，我们放到 2.5 节结合天空渐变再看。

这里再次提醒：8 bit 颜色编号不等于每通道 8 bit。前者是在最多 256 种代表色里选一个；后者是 R、G、B 分别有 256 个等级，可以组合出约 1677 万种颜色。

2.3 编码和解码：图片文件怎样变成屏幕上的像素

保存在磁盘里或从网络下载下来的 JPG、PNG、WebP，本质上都是一段按照特定格式组织的二进制数据。屏幕不能直接把这些压缩数据当成像素显示。

图 7：图片文件保存的是压缩后的二进制数据，必须由对应解码器还原成 RGB 或 RGBA 像素，浏览器或 App 才能把它显示到屏幕上。

图片格式 负责规定尺寸、颜色、透明度以及压缩数据应该怎样保存；图片解码器负责读懂这些规则，把文件中的数据解压并还原成 RGB 或 RGBA 像素。浏览器、Android、iOS 或 App 再对这些像素进行缩放、裁剪和合成，最后交给屏幕显示。

完整过程可以写成：

原始像素 → 编码和压缩 → 图片文件中的二进制数据
图片文件 → 读取或下载 → 解码和解压 → RGB / RGBA 像素 → 浏览器或 App → 屏幕

解码不一定要等整个文件下载完才开始。有些格式支持边下载边解码，浏览器也可能等图片即将进入屏幕时再解码。但无论具体时机怎样，图片最终都要先变成像素，才能被画到屏幕上。

解码器可能由浏览器内置、操作系统提供，也可能由 App 自己集成。这也是图片格式存在兼容性问题的原因：设备即使下载了完整文件，如果没有对应的解码器，仍然无法正确读懂和显示它。

这里再解释一下"无损编码"。它不一定是简单地"给每一种颜色换一个符号"，核心是：只改变信息的记录方式，不删除原始信息，解码后能得到完全相同的像素。

例如，一排像素的某个颜色通道是：

原始数值：100、102、103、103

编码器可以先保存第一个数值，再预测后面的数值与前一个接近，只记录差值：

保存内容：100、+2、+1、0

解码器使用同样的预测规则，再把差值加回去，就能准确恢复出 100、102、103、103。预测错了也不要紧，因为真正的差值仍然完整保存在文件里。PNG 会使用类似的可逆过滤和预测思路，再用压缩算法继续缩小这些重复数据和小差值。

可以用两句话记住：

无损编码是"换一种写法，信息一个不少"；有损编码是"先删掉或近似一部分信息，再把剩下的内容保存下来"。解码只能还原文件里仍然存在的信息，无法找回有损压缩已经删除的部分。

到这里，我们只需要分清编码、解码和无损的含义。接下来再把这套判断放回 PNG 压缩流程中。

2.4 PNG 不是无损格式吗？为什么还会损失颜色

先记住结论：

PNG 编码可以无损保存收到的像素；但如果编码前已经把原图量化成 256 色，从原图到最终 PNG 的完整处理流程仍然是有损的。

图 8：PNG 编码本身可以无损；真正丢失颜色的是前面的颜色量化，所以完整处理流程仍然有损。

为什么会这样？"PNG 支持无损压缩"只说明：PNG 可以把当前交给它的像素准确保存下来，解码时还能还原这些像素。

如果压缩前没有改动像素，流程是：

原图像素 → PNG 无损编码 → 解码后像素相同

如果先把原图的许多颜色合并成 256 种代表色，再保存成 PNG，流程就变成：

原图颜色 → 颜色量化 → 256 色图片 → PNG 无损编码

PNG 的"无损"是指编码和解码前后的像素一致：解码后可以准确还原交给 PNG 编码器的像素。如果编码前已经把原图约 70 万种颜色量化成 256 种，颜色损失就已经发生了。PNG 只能无损保存这份 256 色结果，不能恢复量化时被删除的颜色。因此，PNG 编码本身是无损的，但从原图到最终文件的完整处理流程仍然是有损的。

这里还要补充一个边界：PNG 格式本身使用无损编码。平时所说的"有损 PNG 压缩"，通常是压缩工具先进行颜色量化，用较少的代表色近似原图，再把量化后的像素无损保存成 PNG。量化时可以保留 256 色，也可以使用 224、128、64 等其他数量。因此，不是所有 PNG 压缩都会减少颜色，有损 PNG 也不一定固定使用 256 色。

可以用一句话记住：

PNG 无损保存，不等于生成 PNG 之前的处理过程也无损。

判断是否有损，不要只看文件后缀。把原图和结果图都解码成像素：如果像素颜色发生了变化，相对于原图就是有损；如果像素完全一致，才是像素级无损。

2.5 为什么颜色减少后会出现色带

我们用天空渐变举例。原图可能记录了很多种非常接近的蓝色：

浅蓝 → 稍深一点 → 再深一点 → 更深一点 → 深蓝

这些颜色变化很小，连在一起时看起来很平滑。压成 256 色后，整张图片只能建立一张最多包含 256 种代表色的调色板。调色板颜色可以被任何像素重复使用，但人物、文字、树木和天空通常需要不同的代表色。量化工具要同时照顾整张图片，最终调色板中与天空接近的蓝色可能只有一部分。

这并不是"树木把颜色用掉后，天空就不能再用"，而是有限的调色板位置已经保存了绿色、肤色和文字颜色，就无法同时再保存更多层次的蓝色。天空仍然可以选择任何调色板颜色，只是选择不合适的颜色会产生明显色差。

没有进入调色板的颜色不会被留在文件里。压缩工具只能找到一个最接近的代表色来替换它。于是，原来许多略有差别的蓝色会被合并：

原图：蓝色 1 → 蓝色 2 → 蓝色 3 → 蓝色 4 → 蓝色 5
压缩：浅蓝   → 浅蓝   → 中蓝   → 深蓝   → 深蓝

原本连续的颜色变化变成了一段浅蓝、一段中蓝、一段深蓝。颜色交界处像台阶一样被看见，就形成了一圈圈或一条条的色带，也叫色阶断层。

颜色越少，不同原色被合并到同一种代表色的机会越大。因此，同一张渐变图压成 16 色，通常会比压成 256 色出现更明显的色带。

这不是分辨率不足。分辨率回答"有多少个像素格子"，颜色数量回答"这些格子能从多少种颜色中选择"。一张图片即使有 4K 像素，如果整张图只允许使用 16 种颜色，渐变仍然可能一层一层地断开。

2.6 抖动怎样减少色带，又为什么会出现颗粒

先记住结论：

抖动不会创造新颜色。抖动颗粒不是额外添加的一层噪点，而是不同代表色的像素交错排列后产生的视觉颗粒。

图 9：不加抖动时容易看到成片色带；加入抖动后色带会减轻，但近看可能出现细小颗粒。

减少色带的一种常见办法叫抖动（Dither）。

假设调色板只有浅蓝和深蓝，没有我们需要的中间蓝。不加抖动时，压缩工具只能把一整片区域都换成浅蓝或深蓝，两个色块的边界就很明显。

加入抖动后，压缩工具会让一部分像素使用浅蓝，另一部分使用深蓝，并把它们交错排列。图片里仍然只有调色板已经保留的两种蓝色；但正常观看时，这些小点离得很近，眼睛会把它们混合成接近中间蓝的感觉，原本整齐的色带也就不那么明显。

不加抖动：浅蓝浅蓝浅蓝｜深蓝深蓝深蓝
加入抖动：浅蓝深蓝浅蓝｜深蓝浅蓝深蓝

正常距离观看时，渐变会更自然；放大后，深浅交错的像素仍然存在，因此会表现为细小颗粒。抖动越强，色带可能越不明显，颗粒感通常也越明显。

它和相机在暗光环境中产生的感光噪点不是同一个来源，也和 JPG 低质量压缩产生的方块、边缘振铃不是同一种问题。更准确的名称是抖动颗粒 或抖动纹理。

抖动还可能让文件更难压缩。PNG 擅长压缩连续、重复、容易预测的颜色，而抖动会打散这些规律，让相邻像素频繁变化。抖动越强，像素排列通常越零碎，压缩后的文件也可能越大。

2.7 色差、色带和抖动颗粒不是一回事

前两节已经解释了色带和抖动，这里只把三个容易混淆的名称分清：

• 色差：压缩后的颜色与原图不完全一致，是一种宽泛的颜色误差，不一定能被肉眼直接发现；
• 色带：许多相近颜色被合并后，渐变区域出现肉眼可见的颜色台阶；
• 抖动颗粒：工具为了打散色带，把不同代表色交错排列后产生的视觉颗粒。

它们的关系是：颜色量化可能先产生色差；当渐变中的色差形成明显台阶时，我们看到的是色带；加入抖动可以减轻色带，但可能让颗粒更明显。

这些只是颜色量化中最典型的问题，并不代表所有图片压缩只有色带和颗粒。其他压缩方式还可能带来细节丢失、整体模糊、JPEG 方块、轮廓附近的振铃或毛边、颜色偏移以及透明边缘异常。

2.8 实际压缩时，怎样减少色带和抖动颗粒

没有一个参数能同时做到"颜色特别少、体积特别小、渐变完全平滑、画面又没有颗粒"。实际处理时，可以按下面的顺序判断：

1. 不要把颜色减得太狠：提高允许使用的颜色数量，能保留更多相近颜色。
2. 提高质量档位：让压缩工具在损失明显时少合并颜色，或者直接保留原图。
3. 对渐变适量使用抖动：用细小颗粒打散明显色带，但不要把颗粒加得过重。
4. 大面积渐变谨慎使用调色板压缩：天空、阴影、发光和半透明边缘对颜色变化更敏感。
5. 按实际显示尺寸检查：既要正常观看，也要放大检查色带、文字边缘、透明边缘和颗粒。

最后提醒：分辨率高也补不回被颜色量化删掉的信息。一张 4K、16 色的图片，不一定比一张 1080p、真彩色图片更好看。

3. 透明度：RGBA 不是"更多颜色"

这里先记住结论：

这里的"分辨率"特指图片分辨率：图片文件里横向和纵向各有多少图片像素。手机参数里的"屏幕分辨率"则表示屏幕横向和纵向各有多少物理像素。两者都写成"宽 × 高"，但数的不是同一种像素。

图 10：图中的分辨率指图片分辨率；它和色深、透明度是三件不同的事。

先用一个例子区分图片分辨率和屏幕分辨率：

• 一张 720 × 360 的 Banner，表示图片文件里有 720 列、360 行图片像素；
• 一块 1080 × 2400 的手机屏幕，表示屏幕横向有 1080 个、纵向有 2400 个物理像素，也就是发光小格子。

把这张 Banner 放到手机上，图片不会自动变成 1080 × 2400。浏览器只会根据它的 CSS 显示尺寸和屏幕 DPR，把图片像素映射到屏幕中的一部分物理像素上。前面讲的"图片像素尺寸 ≥ CSS 显示尺寸 × DPR"，比较的正是图片能提供的像素，是否足够填满实际用于显示它的物理像素。

区分清楚以后，我们再按图中的三个区域逐项看：

• 图片分辨率：图片文件里有多少个图片像素格子；
• 每通道色深：每个颜色通道能记录多少等级；
• 透明度：每个像素能透过去多少。

这三者会一起影响观感，但不能互相替代。调色板颜色数又是另一项限制，它表示整张图片最多能共用多少种代表色，不能和每通道色深混为一谈。

现在再看 RGB 和 RGBA。这里先记住一句话：

RGB 只负责颜色；RGBA 多出来的 A 是 Alpha，负责透明度。同一个 Logo 没有 Alpha 时，周围只能保存已经写进图片的实色背景；带有 Alpha 时，网页背景才能从 Logo 周围透出来。

图 11：RGB 版本会带着已经写进图片的实色底板；RGBA 版本可以让网页背景从 Logo 周围透出来。

我们按图的左右两边看：

• RGB 版本只有 R、G、B 三个颜色通道。图中用白底举例：白色已经成为图片内容的一部分，所以放到深色网页上仍然会看到一块白色方框。
• RGBA 版本在 RGB 之外增加了 Alpha。Logo 外部可以设为完全透明，边缘可以设为半透明，因此放到深色网页上时，页面背景能够自然透出来。

常见的 8 bit Alpha 可以记录 0～255 共 256 个透明等级。0 通常表示完全透明，255 表示完全不透明，中间数值表示不同程度的半透明。

所以一个常见的 32 bit RGBA 图片，通常可以理解成"24 bit 颜色 + 8 bit 透明度"。这里的 A 不是第四种颜色，而是控制当前像素应该显示多少、让背景透出多少。

还要区分两个容易混淆的说法：

• 格式支持透明度：例如 PNG、WebP、AVIF 具备保存 Alpha 的能力；
• 当前文件真的有 Alpha：导出时确实保留了透明通道，而不是提前铺上白色或其他背景。

因此，即使文件后缀是 PNG，如果导出前已经把 Logo 铺在白底上，它仍然会显示白色方框；反过来，常见 JPG 本身不保存这种 Alpha 透明度，透明区域通常会在导出时被填成某种实色背景。

4. 文件格式：同一份内容可以有不同的保存方法

文件格式可以理解成一套保存规则。它会规定：

• 像素或图形怎样记录；
• 是否压缩，以及压缩时会不会丢信息；
• 是否支持透明度；
• 浏览器或其他软件应该怎样解码。

所以，后缀不是清晰度本身。把 photo.jpg 直接改名为 photo.png，只是改了文件名，没有改变内部的编码方式。真正的格式转换，需要先解码原文件，再按照新格式重新编码。

接下来，我们不再罗列很少出现在前端设计稿里的格式，只围绕常见导出菜单中的六个选项来讲。

二、先把六种格式分成三类

这里先记住结论：

JPG、PNG、WebP、AVIF 是位图；SVG 是矢量图；PDF 是文档格式。它们解决的问题不同，不能只按"谁更清晰"排成一列。

图 12：先分清位图、矢量图和文档，再讨论具体应该选哪个后缀。

我们按图中的三类来看：

• 位图：JPG、PNG、WebP、AVIF。它们最终都要保存一格一格的图片像素，照片、Banner、截图通常属于这一类。
• 矢量图：SVG。它主要保存形状、路径、填充和描边，适合图标、Logo 和简单插画。
• 文档：PDF。它主要保存一整页的排版，可以同时包含文字、矢量图和位图，适合交付、审阅和打印。

这也解释了为什么 PDF 不能简单理解成"另一种图片"。一张 JPG 通常只有一幅像素画面；一份 PDF 可能有多页，每页还可以同时放文字、图形和照片。

三、四种常用位图：JPG、PNG、WebP、AVIF

先给一个实用结论：

JPG 重兼容，PNG 重透明和精确边缘，WebP 适合作为现代网页的通用方案，AVIF 更偏向继续压缩体积；最终仍要用真实图片比较画质、体积和工具链。

1. JPG：照片和兼容回退

JPG 使用有损压缩。它会舍弃一部分人眼不敏感的信息，从而让照片明显变小。

它适合：

• 照片；
• Banner；
• 颜色和纹理比较复杂的背景图；
• 需要广泛兼容的回退图片。

它不擅长：

• 透明背景；
• 文字和细线很多的界面图；
• 需要反复编辑、反复保存的母版。

JPG 的 quality 参数不是"还剩百分之多少画质"。同一个 quality 数字，在不同编码器和不同图片上，得到的结果可能不一样。判断是否合格，要同时看文件体积和肉眼效果。

2. PNG：透明截图和 UI 素材

PNG 使用无损编码，并支持 Alpha 透明度。它很适合保存：

• 透明 Logo；
• UI 截图；
• 带文字的流程图；
• 颜色边界清楚的界面素材；
• 需要像素级准确还原的中间结果。

这里的"无损"只指 PNG 编码；如果编码前做过颜色量化，完整处理流程仍然有损，具体原理见前文 2.4 节。

照片通常包含大量细碎纹理。PNG 若要把这些像素都准确保存下来，文件可能很大。因此，"需要透明或精确边缘"适合 PNG，"只要是图片就用 PNG"并不合适。

3. WebP：现代网页的通用方案

WebP 可以使用有损或无损压缩，也可以支持透明度。对前端来说，它的价值是能够覆盖很多原本分别由 JPG 和 PNG 承担的场景。

常见用法包括：

• 照片和 Banner 使用有损 WebP；
• 透明素材使用支持 Alpha 的 WebP；
• 构建或图片服务根据原图自动生成 WebP。

不过，"能导出 WebP"不等于项目一定应该全部换成 WebP。还要确认浏览器范围、图片服务、CDN、预览工具和回退策略是否一致。

4. AVIF：更看重体积时评估

AVIF 同样可以用于照片，也可以支持透明度。它通常具有很有吸引力的压缩效率，适合对图片流量比较敏感的网页。

它的代价可能包括：

• 编码时间更长；
• 某些设计、预览或上传工具支持不完整；
• 老旧环境需要回退；
• 同一参数在不同内容上的效果并不固定。

因此，AVIF 更适合"经过测试后使用"，而不是只因为后缀更新就无条件替换。对同一张图同时导出 AVIF、WebP 和 JPG，比较文件大小、文字边缘、渐变、人物皮肤和解码表现，再决定是否上线。

四、SVG：图标和 Logo 为什么优先用它

先记住结论：

位图保存的是已经画好的像素格，SVG 保存的是形状和绘制规则；放大 SVG 时，浏览器会按新尺寸重新绘制，而不是把一张小图硬拉大。

图 13：位图放大的是已有像素，SVG 放大时会按形状和路径重新计算并绘制。

可以把两者想成两种不同的交付方式：

• 位图像一张已经画好的方格纸：每个格子的颜色都已经确定，图片也只有固定数量的像素。把一张 100×100 的位图放大到 800×800，浏览器只能把原来的像素铺得更大或计算出过渡像素，所以边缘可能出现锯齿或发虚。
• SVG 像一张绘图说明书：它不必保存每个位置最终是什么颜色，而是记录"这里画一条曲线""这里画一个圆""内部填蓝色""边缘描白色"等形状、路径、填充和描边规则。

当 Logo 从 100×100 放大到 800×800 时，浏览器会先按照 SVG 中的规则计算放大后的曲线和边界，再决定屏幕上对应的物理像素应该显示什么颜色。这个把形状变成屏幕像素的过程叫栅格化。最终屏幕当然还是靠物理像素发光，但浏览器每次都从路径重新计算，不需要放大一份固定的 100×100 像素数据，所以轮廓通常仍然平滑。

因此，SVG 放大后清楚不是因为它做了"降噪"，而是因为它保存的原本就不是一张固定分辨率的小图。只要路径本身正确，同一份 SVG 可以按照当前 CSS 尺寸重新渲染，也不需要为 DPR 2 的二倍屏再单独准备一张"二倍 SVG"。

例如，一个圆形只需要记录圆心、半径、填充色和描边。浏览器显示时，再根据当前尺寸把它画出来，不需要提前保存这个圆内部的每一个图片像素。

SVG 适合：

• 图标；
• Logo；
• 简单插画；
• 几何图形；
• 需要跟随 CSS 改颜色的界面图形。

SVG 不适合用来硬装复杂照片。照片有大量不规则纹理，如果强行转换成矢量路径，文件可能非常复杂，编辑和渲染也未必划算。

这里还要注意："SVG 放大后通常不会糊"描述的是矢量路径。如果 SVG 内部嵌入了一张低分辨率 JPG 或 PNG，那部分位图放大后仍然可能发糊；特别细的线条在很小的显示尺寸下，也可能受到像素对齐和渲染方式影响。

五、PDF：它保存的是整页交付结果

PDF 更像一个固定版式的文件盒子。它可以同时装入：

• 可选择和复制的文字；
• 矢量图形；
• JPG、PNG 等位图；
• 多个页面；
• 页面尺寸和排版信息。

所以设计稿提供 PDF，通常是在表达："把这一页按当前排版交付出去。"它常用于：

• 打印；
• 方案审阅；
• 简历、海报和宣传页交付；
• 需要保留整页布局的文件；
• 对方明确要求 PDF 的工作流。

PDF 通常不是网页中一张普通图片的替代品。浏览器可以预览 PDF，但前端不会因为要显示一个 Banner，就把 PDF 当成普通的 img 素材。

PDF 也不保证里面的图片一定清晰。如果 PDF 中嵌入的本来就是低分辨率位图，把页面放大后，那张位图仍然会糊；只有文字和矢量图形可以继续按路径清晰绘制。

六、设计稿下载时，直接按场景选择

前面已经分别讲过六种格式，现在把它们放回设计稿的实际下载场景中。

图 14：先判断交付内容，再从六种格式中选择，不要只比较后缀新旧。

格式	类型	压缩与透明	前端常见用途
JPG	位图	有损，通常不支持透明	照片、Banner、兼容回退
PNG	位图	无损编码，支持 Alpha	透明素材、截图、文字和 UI
WebP	位图	可有损或无损，可支持透明	现代网页图片、通用交付
AVIF	位图	可有损或无损，可支持透明	对体积敏感的现代网页
SVG	矢量图	保存路径和形状，可透明	图标、Logo、简单插画
PDF	文档	可包含文字、矢量图和位图	整页交付、审阅、打印

这张表给的是默认方向，下面再说明为什么这样选。

照片和 Banner：优先测试 WebP、AVIF，并准备 JPG 回退。

照片包含大量连续色彩、光影和纹理，通常没有必要逐个精确保存所有像素。WebP、AVIF 和 JPG 可以通过有损压缩删除一部分不容易察觉的信息，从而明显减小体积。WebP、AVIF 通常用于继续节省流量，JPG 则适合作为兼容范围更广的回退格式。

透明 UI、界面截图和带文字素材：优先考虑 PNG，也可以测试 WebP/AVIF。

这类图片常有透明背景、文字、细线和清楚的颜色边界。PNG 支持 Alpha 透明度，并且能无损保存交给编码器的像素，因此边缘不容易出现 JPG 低质量压缩常见的模糊、杂边和方块。即使截图不透明，只要里面有大量小字、表格线或清晰 UI 边缘，PNG 仍然可能更合适。若工具链和目标环境支持，也可以测试带透明度的 WebP 或 AVIF，再比较画质和体积。

图标和 Logo：优先确认能否直接使用 SVG。

图标和 Logo 通常由有限的几何形状、颜色和路径组成，正好适合用 SVG 描述。浏览器可以按当前尺寸重新绘制，简单 SVG 的体积也可能很小，还可以通过 CSS 调整颜色。拿不到矢量源文件、图形包含复杂纹理，或者使用环境不接受 SVG 时，再改用 PNG 等位图。

所以，实际选择顺序是：先看内容类型，再看透明度，最后结合兼容性和压缩结果选择格式。

七、前端项目里怎样落地

1. 先确定图片显示尺寸

位图上线前，先用下面的公式检查像素是否够用：

图片像素尺寸 ≥ CSS 显示尺寸 × DPR

例如，Banner 显示为 360 CSS px，目标设备是 DPR 2 的二倍屏，至少准备 720 px 宽的位图。小于这个尺寸时，浏览器需要放大图片，文字和边缘可能发虚；明显超过这个尺寸，通常不会在二倍屏上更清楚，反而会增加下载和解码成本。

SVG 不需要按 DPR 分别导出一倍图、二倍图；确认文件保存的是有效矢量内容且 viewBox 正确后，直接使用同一份 SVG 即可。

2. 用 picture 提供现代格式和回退

如果项目需要兼顾现代格式和旧环境，可以让浏览器按顺序选择：

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img
    src="hero.jpg"
    width="720"
    height="360"
    alt="活动 Banner"
  />
</picture>

浏览器会从上往下选择自己能够使用的来源。如果 AVIF 不可用，就继续尝试 WebP；都不合适时，最后使用 img 中的 JPG。

如果素材需要透明，最后的回退也可以根据内容改成 PNG。

3. PDF 单独走交付流程

需要 PDF 时，不要只检查网页预览。还要检查：

• 页面尺寸是否正确；
• 字体有没有被替换；
• 图片是否达到打印所需清晰度；
• 文字和矢量内容是否仍然可选择；
• 对方打印或审阅软件能否正常打开。

八、几个最容易踩的坑

坑 1：改后缀就是格式转换

不是。photo.jpg 改名为 photo.png，内部仍然是 JPEG 编码。真正转换需要软件重新解码和编码。

坑 2：图片像素不够，换成 AVIF 就会变清楚

不会。格式可以改变保存和压缩方式，但不能凭空增加原图没有记录的真实细节。

坑 3：PNG 无损，所以压缩 PNG 一定无损

不一定。PNG 编码本身可以无损，但压缩工具可能在编码前先做颜色量化。判断完整流程是否有损，要比较处理前后的像素。

坑 4：四倍图放在二倍屏一定比二倍图更清楚

通常不会。二倍屏只有对应数量的物理像素，多出来的图片像素会在缩小时被筛选和合并，却会增加下载体积。

坑 5：SVG 永远不会糊

只有矢量路径可以继续清晰绘制。如果 SVG 里面嵌入低分辨率位图，那部分仍然可能发糊。

坑 6：导出 PDF 就等于印刷质量

不等于。PDF 可以保存页面结构，但其中的位图、颜色配置和字体仍然可能不符合印刷要求。

坑 7：AVIF 一定比 WebP 更适合

不一定。AVIF 的压缩效率很有吸引力，但编码速度、解码表现、兼容范围和工具链也要一起测试。

九、把今天的内容压缩成九句话

1. JPG、PNG、WebP、AVIF 是位图，清晰度首先受图片像素尺寸影响。
2. SVG 是矢量图，适合图标、Logo 和简单插画。
3. PDF 是文档格式，适合保留整页排版、交付和打印。
4. 页面所需图片像素，可以用"CSS 显示尺寸 × DPR"估算。
5. JPG 适合照片和兼容回退，但不适合透明素材。
6. PNG 适合透明、截图和精确边缘，无损不等于文件一定小。
7. WebP 和 AVIF 适合现代网页，但上线前仍要检查画质、体积和兼容性。
8. 现代格式可以用 picture 配合 JPG 或 PNG 回退。
9. 先判断内容和交付场景，再选择后缀。

如果你只记住一句话，就记这个：

先分清要交付的是位图、矢量图还是整页文档，再在对应范围里选择格式。