PNG格式详解：分块结构、无损压缩与体积优化实战

1. 先弄清楚 PNG 的定位：它在什么场景下不可替代

前阵子帮一个做工具类客户端的模拟项目排查安装包体积，问题听上去很小：一批界面素材打进去之后，包体从 18M 涨到了 31M。翻了半小时发现，三十多张图标和引导页全部是从设计稿直接导出的PNG，而且清一色 16 位真彩加透明通道，其中大部分其实是纯色扁平图标，用 8 位索引色就能表达得一模一样。把它们重新量化加无损压一遍，包体回到 20M 出头，肉眼完全看不出差别。这类事情我这些年撞见太多次了——关于 PNG 格式详解的资料网上一抓一大把，但真正讲清楚“这张图为什么这么大”“透明边缘为什么发黑”“同一张图换个工具压出来体积差一倍”的并不多，大部分人只是把它当成“带透明的图片格式”在用。

这篇内容我想把它彻底讲透：PNG 的文件结构长什么样、像素数据是怎么被压缩的、怎么自己写代码把它解出来、体积到底该怎么压、以及在透明和缩放这两个最容易翻车的地方有哪些坑。适合两类人看：一类是做前端、客户端、图像处理的开发者，需要判断“这个素材该不该用 PNG、怎么压”；另一类是对文件格式本身好奇、想搞明白“图片到底是怎么存起来”的爱好者。哪怕你之前只会用导出按钮，看完也应该能对着一张 PNG 说出它大概是什么颜色类型、位深几许、还能不能压。

1.1 一次素材返工带来的选型反思

那次返工之后我复盘了一下，问题的根源不在工具，而在选型思路：很多人挑图片格式是凭感觉的——“有透明就用 PNG，没透明就用 JPG”，这个判断只对了一半。PNG 真正的价值是逐像素无损加上完整的 Alpha 通道，这两点决定了它在哪类素材上不可替代：界面元素、图标、线稿、文字截图、需要反复编辑的中间素材、带锐利边缘的图形。这些内容的共同点是高频细节多、颜色过渡少，一旦上 JPEG 那种基于 8×8 块的离散余弦变换，文字边缘立刻出现蚊子状噪点，色块交界处出现振铃，第二次保存还会继续劣化。

反过来，PNG 在照片类内容上是彻底的劣势。一张 1920×1080 的风景照，JPEG 质量 85 大概 300KB 到 500KB，同样尺寸的 PNG 轻松上到 3M 到 5M，差距接近十倍。原因很直白：PNG 的压缩是纯粹的熵编码，它不丢弃任何信息，只负责把重复模式用更短的编码表示。照片的像素值几乎是连续随机的，找不到多少重复模式，自然压不动。所以我在项目里给自己定了一条硬规矩：照片、渐变背景、大面积复杂纹理，一律不用 PNG；只有需要无损、需要透明、或者需要后续再编辑的素材才留给它。

1.2 PNG 的三条技术主线：无损、透明、分块流式

理解 PNG 可以抓住三条主线。第一条是无损：解码出来的像素值必须和编码前逐字节一致，这是格式的硬承诺，也是它敢用在设计和存档场景的底气。第二条是Alpha 通道，而且是非预乘的直通 Alpha，这让它可以表达任意形状的镂空、半透明蒙版、柔和投影。第三条是分块结构：整个文件由一个个带长度和校验的块串起来，解码器可以跳过不认识的辅助块继续出图，这让格式具备了向前兼容的扩展能力。

分块设计带来的另一个好处是流式解码。图像数据被切成多个 IDAT 块，解码器边读边解压边输出，不必把整个文件先塞进内存再处理。对于当年内存紧张的环境，这是个关键设计。带宽和内存都不再是瓶颈的今天，这个特性依然有用——比如在服务端做图片校验时，你可以只读到 IHDR 就判断尺寸和颜色类型，发现超限直接拒绝，连像素数据都不用解。

还有一点常被忽略：PNG 诞生于上世纪九十年代中期，当时另一种常见的无损格式受授权限制，社区需要一个完全开放、免费、无附加条件的替代方案。PNG 就是在这个背景下被设计出来的，所以它的规范写得非常克制——不追求压缩率极致，优先保证实现简单、无歧义、可验证。理解了这一点，你就明白为什么它的压缩算法选择的是 DEFLATE 而不是更复杂的方案。

1.3 什么情况下应该果断放弃 PNG

有三种情况我会毫不犹豫地换掉 PNG。第一种是纯照片内容，前面已经说过，体积差距摆在那里。第二种是超大尺寸的展示图，比如 8000×6000 的展板或海报，PNG 解码后仅像素缓冲区就要 192MB（RGBA8），移动端很可能直接 OOM，这时候要么降尺寸，要么换支持分块解码的格式。第三种是动画，虽然 APNG 技术上可行，但它的每一帧都是完整编码，体积通常是视频编码的十几倍，除了极短的简单动效，我都建议走视频或者序列帧方案。

还有一个容易被忽略的判断点：这张图会不会被反复编辑。如果素材要在设计工具里反复打开保存，PNG 几乎是唯一选择，因为 JPEG 每次保存都有损，几轮下来画面就糊了。如果只是最终交付、不再改动，那就可以按内容特征自由挑选更省体积的格式。我在模拟项目里通常会把素材分成“源文件”和“交付件”两套：源文件用 PNG 保真，交付件按场景压缩甚至转格式，两套分开管理，避免互相牵制。

2. 拆开一个 PNG 文件：从 8 字节魔数到 IEND

想真正搞懂 PNG，最快的方式不是背规范，而是拿一个文件用十六进制编辑器打开看。前 8 个字节永远是固定的89 50 4E 47 0D 0A 1A 0A，这串东西不是随便拍的：最高位为 1 用来检测传输过程中是否被剥掉了第 8 位，后面50 4E 47是 ASCII 的 “PNG”，再跟0D 0A做换行符转换检测，最后的1A是文件结束符，防止在终端里cat出来乱码，0A再兜一次底。这 8 个字节的设计细节，基本能体现整个格式的设计哲学——每个字节都有明确理由。

签名之后就是一个个块，块的排布非常规整：4 字节长度、4 字节类型、若干字节数据、4 字节 CRC。长度只算数据部分，不含长度字段、类型字段和 CRC 本身，这点在实现时特别容易写错。类型是 4 个 ASCII 字母，大小写有含义：第一个字母大写表示关键块，解码器不认识就必须报错；小写表示辅助块，不认识可以直接跳过。第四个字母大写表示安全复制，即使在编辑文件时也可以原样搬过去。

2.1 块结构是理解 PNG 的第一把钥匙

把块结构吃透，很多现象就自动解释了。比如为什么一个 PNG 中间坏了几百字节，后面还能解出一部分图？因为每个块都有独立的 CRC，解码器逐块校验，坏块跳过，后面的 IDAT 还能继续解。再比如为什么有些 PNG 里会多出一堆看不懂的块（文本、色彩配置、物理尺寸），却不影响显示？因为它们是辅助块，解码器按规则忽略即可。

关键块只有四个：IHDR必须是第一个，IEND必须是最后一个，IDAT存放压缩后的像素数据，PLTE是索引色的调色板。规范要求所有 IDAT 块必须连续出现，中间不能插别的块，否则视为非法。这条规则在拼图工具里经常被违反——有些粗糙的实现会把文本块插在两个 IDAT 中间，结果在某些严格解码器上直接打不开。

辅助块里比较常用的有：tRNS透明信息、gAMA伽马、sRGB色彩空间、iCCP嵌入色彩配置、pHYs物理像素尺寸、bKGD建议背景色、tEXt／zTXt／iTXt三种文本块、eXIf交换图像元数据、tIME最后修改时间。如果看的是动图，还会遇到acTL、fcTL、fdAT三个 APNG 专有块。

2.2 IHDR 里的 13 个字节决定了后面所有解码逻辑

IHDR 的数据长度固定 13 字节，依次是：宽 4 字节、高 4 字节、位深 1 字节、颜色类型 1 字节、压缩方法 1 字节、滤波方法 1 字节、交错方法 1 字节。全部是大端序，这是网络字节序的传统。宽高最大可以到 2³¹-1，但实际实现里几乎没有解码器能吃下这么大的图，内存会先炸掉。

颜色类型只有五种合法值，这是整个解码流程的分叉点：

• 0：灰度，单通道
• 2：真彩，RGB 三通道
• 3：索引色，像素值指向 PLTE 里的表项
• 4：灰度加 Alpha，双通道
• 6：真彩加 Alpha，四通道

位深与颜色类型的组合有严格限制，不是随便填的。灰度支持 1、2、4、8、16 位；真彩只支持 8 和 16 位；索引色支持 1、2、4、8 位；带 Alpha 的两种只支持 8 和 16 位。这套组合决定了每像素的原始位数，进而决定每行的字节数怎么算。

提示：如果你拿到一张 PNG，发现它体积异常大，先看 IHDR 的位深是不是 16。很多设计工具默认导出 16 位，而绝大多数屏幕和浏览器最终只按 8 位显示，多出来的 8 位完全是浪费。

压缩方法和滤波方法在现行规范里都只有 0 这一个合法值，分别代表 DEFLATE 和标准五类滤波。交错方法0 表示不交错，1 表示 Adam7 七遍交错。交错会把图像分成七个不同分辨率的子图依次存储，好处是网络慢的时候能先看到模糊轮廓再逐步清晰，坏处是压缩率下降、解码逻辑复杂。现在几乎没有场景需要它，我在导出时一律关掉。

2.3 那些容易被忽略的辅助块

PLTE的每一项是 3 个字节的 RGB，最多 256 项。索引色 PNG 的像素值不是颜色，而是这个表的索引，所以改调色板能整体换配色，这个特性在主题切换场景里很好用——同一张灰度索引图配不同的 PLTE 就能出不同色调，省掉一堆素材。

tRNS的含义随颜色类型变化，这是最容易踩坑的地方。对索引色，它是一张和 PLTE 等长的 Alpha 表，每项 1 字节，可以实现逐索引的半透明，最多 256 级；对灰度，它是 2 字节，表示“等于这个灰度值的像素全透明”；对真彩，它是 6 字节，表示“等于这个 RGB 组合的像素全透明”。也就是说，非索引色 PNG 的 tRNS 只能做单色抠除，做不出半透明渐变，想要真正的 Alpha 必须用颜色类型 4 或 6。

gAMA存的是伽马值乘以 100000 的整数，比如 1/2.2 约等于 0.45455，存进去就是 45455。它告诉解码器“这张图的数据是在什么伽马下编码的”，解码器据此做转换。麻烦在于各家实现历史上对它的处理并不一致，导致同一张图在不同软件里亮度有细微差别。sRGB块的存在就是为了简化这件事，它直接声明“按标准 sRGB 处理”，优先级高于 gAMA。

pHYs是 9 字节：水平密度 4 字节、垂直密度 4 字节、单位 1 字节（0 表示未知比例，1 表示每米像素数）。做打印输出时必须看这个，否则 300dpi 和 72dpi 的图在排版软件里尺寸会差四倍多。

iCCP里塞的是完整的 ICC 色彩配置，zlib 压缩过。带这个块的 PNG 在不同色域的设备上能保持一致显示，代价是文件多出几 KB 到几十 KB。做品牌物料、印刷交付时值得带上，做普通网页素材就没什么必要。

2.4 像素数据为什么不是“原样”存进去的

IDAT 里的内容不是像素原始字节，而是经过两步处理：先滤波，再 DEFLATE 压缩。滤波是 PNG 压缩效果的关键，也是很多人分析体积时忽略的一环。

滤波的做法是：每一行像素在存储前，先减去一个“预测值”，只存差值。因为相邻像素通常高度相关，差值大多接近 0，而连续的 0 在 DEFLATE 里能被压得极短。规范定义了五种滤波类型，每行开头用 1 个字节标明本行用的是哪种：

• 0 None：不预测，直接存原值
• 1 Sub：减去左边相邻像素
• 2 Up：减去上一行同位置像素
• 3 Average：减去左边和上边的平均值
• 4 Paeth：减去左、上、左上三者推算出的预测值

Paeth 的预测函数是p = a + b - c（a 左、b 上、c 左上），然后比较 p 与三者的距离，取最近的那个作为预测值。这个函数在平滑渐变区域效果极好，但对噪声多的照片反而不如 None。所以编码器通常会逐行试算五种滤波，选绝对值和最小的那个，这就是所谓“自适应滤波”。

注意：滤波是对字节做的，不涉及通道语义。计算左邻居时是按“每像素字节数”往回退，而不是退 1 个字节。位深小于 8 时，每个字节里塞了多个像素，这个偏移量要按向上取整到整字节来算，写代码时这里错一步，解出来的图就全是彩色噪点。

3. 手写一个 PNG 解析器：把解析流程跑通

光看规范容易浮在表面，真正动手写一遍解码器，很多细节才会钉死。我建议每个做图像相关工作的同行都至少写一次，不用写完整，能解出 RGBA 就够。下面这套代码我在模拟项目里跑过，能正确解出常见的非交错 PNG。

3.1 最小骨架与逐块读取

第一步是切块。读文件后校验 8 字节签名，然后循环读长度、类型、数据、CRC，直到遇到 IEND。长度字段是大端 4 字节，用struct.unpack('>I', ...)即可。

import struct import zlib def read_chunks(path): with open(path, 'rb') as f: data = f.read() if data[:8] != b'\x89PNG\r\n\x1a\n': raise ValueError('not a png') pos = 8 chunks = [] while pos < len(data): length = struct.unpack('>I', data[pos:pos + 4])[0] ctype = data[pos + 4:pos + 8] cdata = data[pos + 8:pos + 8 + length] crc = struct.unpack('>I', data[pos + 8 + length:pos + 12 + length])[0] calc = zlib.crc32(ctype + cdata) & 0xffffffff if crc != calc: print('crc mismatch at', ctype, pos) chunks.append((ctype, cdata)) pos += 12 + length if ctype == b'IEND': break return chunks

这里有个细节值得说：CRC 的计算范围是类型字段加数据字段，不包括长度，也不包括 CRC 自己。CRC 用的是标准 CRC-32，多项式 0xEDB88320，初值全 1，结果取反，Python 的zlib.crc32直接就是这套，拿来即用。

3.2 CRC 校验与常见损坏特征

CRC 不匹配说明数据在传输或存储中出了问题。实际排查时，不同的损坏位置表现不同：如果坏在 IHDR，整张图打不开；坏在 IDAT 的开头部分，图的上半部分会花；坏在中间，从某一行开始整片错乱；坏在末尾，下面一大块变灰或变透明。有些查看器比较宽容，跳过坏块继续画，有些直接报错，这就是“同一张图在我这能开、在他那打不开”的常见原因之一。

我在服务端做素材上传校验时，会把 CRC 校验当成第一道关：块结构走一遍，CRC 全部通过才继续后面的大小、尺寸、颜色类型检查。这一步成本很低，但对于拦截传输截断特别有效——网络中断导致的半截文件，最后几个块的 CRC 基本都会挂掉。

提示：如果手头只有损坏的文件、没有原始文件，先试着把文件尾部的 IDAT 补全或者直接截断到最后一个完整块，很多查看器就能打开看到前半部分内容，至少能救回一部分素材。

3.3 解压、反滤波到像素还原

拿到所有 IDAT 的数据后先拼接，再整体 zlib 解压，得到的是“每行前面带 1 字节滤波类型、后面跟行像素数据”的字节流。接下来按行反滤波。

def unfilter(raw, width, height, bits_per_pixel): bpp = max(1, (bits_per_pixel + 7) // 8) row_bytes = (width * bits_per_pixel + 7) // 8 out = bytearray() prev = bytearray(row_bytes) pos = 0 for _ in range(height): ft = raw[pos] pos += 1 line = bytearray(raw[pos:pos + row_bytes]) pos += row_bytes for x in range(row_bytes): a = line[x - bpp] if x >= bpp else 0 b = prev[x] c = prev[x - bpp] if x >= bpp else 0 if ft == 1: line[x] = (line[x] + a) & 0xff elif ft == 2: line[x] = (line[x] + b) & 0xff elif ft == 3: line[x] = (line[x] + ((a + b) >> 1)) & 0xff elif ft == 4: p = a + b - c pa, pb, pc = abs(p - a), abs(p - b), abs(p - c) if pa <= pb and pa <= pc: pred = a elif pb <= pc: pred = b else: pred = c line[x] = (line[x] + pred) & 0xff out += line prev = line return bytes(out)

反滤波必须按行顺序做，因为 Up 和 Paeth 都依赖上一行已经还原的结果。这也是为什么不能并行解码单个 IDAT 内部数据的原因，只能按行推进。

3.4 位深与颜色类型的展开与参数计算

反滤波拿到的还是按位打包的紧凑数据，位深小于 8 时要按位展开。1 位灰度每字节装 8 个像素，索引色 4 位每字节装 2 个。展开时要注意行尾填充：如果一行像素位数不是 8 的整数倍，末尾会补零到整字节，这些填充位不能当成像素。

每行字节数的公式是ceil(width * bitDepth * channels / 8)，其中 channels 由颜色类型决定：灰度 1、灰度加 Alpha 2、真彩 3、索引色 1、真彩加 Alpha 4。滤波用的 bpp 是ceil(bitDepth * channels / 8)，且最小为 1，这点很关键——1 位灰度图的 bpp 是 1 而不是 0.125。

举个具体例子：一张 100×50 的 4 位索引色图，每像素 4 位、1 通道，所以每像素位宽 4，每行字节数ceil(100*4/8) = 50，其中前 100 个 4 位值分别是 100 个像素的调色板索引，如果需要奇偶展开就是高 4 位在前。整张图解压后是50 * (50 + 1) = 2550字节（每行多 1 字节滤波标记），这个数可以用来快速验证解压结果对不对。

如果遇到 Adam7 交错，需要把七个 pass 分别解一遍再拼回完整图像。每个 pass 的宽高按ceil((width - x_start) / x_step)算，七个 pass 的起始偏移和步长分别是 (0,0)/(8,8)、(4,0)/(8,8)、(0,4)/(4,8)、(2,0)/(4,4)、(0,2)/(2,4)、(1,0)/(2,2)、(0,1)/(1,2)。拼的时候按各自的偏移把像素填回大图。这段逻辑写起来啰嗦，但原理就是把一张图拆成七种稀疏采样分别存。

4. PNG 体积优化：从“能看”到“够小”

体积优化是我在实际工作里花时间最多的一块，因为效果立竿见影。优化分两条路：有损量化和无损压缩，两者可以叠加使用，先量化再无损压，通常能得到最小结果。

4.1 有损量化：用 256 色换掉七成体积

量化的思路是把颜色数降到 256 以内，然后转成索引色 PNG。因为每个像素只需要 1 个字节的索引，加上调色板才 768 字节，颜色数据量直接降到原来的四分之一（对比 RGBA8）。再配合索引值的高度重复，DEFLATE 能压得非常狠。

实现上常见两种算法：中位切分和八叉树。中位切分的做法是把所有颜色放进 RGB 立方体，找到方差最大的那个轴，沿中位数切开，重复直到切成目标数量，每块取平均色。八叉树则是一层层细分颜色空间，把低频分支合并。两者效果接近，前者实现直观，后者在大图上快一些。为了弥补降色带来的色带，通常会加抖动，用邻域误差扩散的方式把量化误差摊到相邻像素上，视觉上更平滑。

命令行最常用的是 pngquant，我一般这么写：

pngquant --quality=65-85 --speed 1 --strip --output out.png in.png

--quality给一个区间，工具会尝试不同色数直到落在区间内，低于下限就放弃并返回非零退出码；--speed 1是最慢也就是质量最好的档位；--strip去掉所有辅助块。量化对图标、扁平插画、UI 素材效果好得离谱，一张 200KB 的图标常常能压到 40KB 以下，肉眼几乎看不出差别。但对照片、天空渐变、柔和阴影就不行了，色带会非常明显。

注意：量化会破坏“无损”这个前提，源文件务必保留一份未量化的版本。我在模拟项目里会把量化后的文件加后缀区分，绝不覆盖原图。

4.2 无损压缩：滤镜策略与压缩器选择

无损压缩不改动任何像素，只是换更聪明的编码方式。可优化的点有三个：滤波策略、DEFLATE 参数、块划分。

滤波策略方面，PNG 编码器默认会做自适应选择，但不同实现的启发式规则不一样。有些工具会暴力尝试“全部用某一种滤波”的若干组合，找出压缩后最小的方案。oxipng 就是这类思路，它的-o参数从 0 到 6，等级越高尝试的组合越多、耗时越长。经验上-o 4能拿到大部分收益，-o 6再加--zopfli能多挤出几个百分点，但耗时可能翻十倍，适合对体积敏感的交付场景，不适合放进每次构建的流水线。

DEFLATE 参数上，zlib 的压缩级别 1 到 9，级别 9 比级别 6 通常只小 1% 到 3%，但慢好几倍。zopfli 用的是迭代式的最优路径搜索，比 zlib 9 还能再小 5% 到 10%，代价是几十倍的耗时。我在实际使用中的判断标准是：单张图超过 100KB 且会进包体，就值得上 oxipng 高档位；小于 20KB 的图标，-o 2就够了，因为小图本身压缩空间有限。

块划分指的是 IDAT 切多大。切得太小，每块要额外背 12 字节开销；切得太大，流式解码时首屏出图慢。一般工具默认 8KB 到 32KB，不需要手动干预，除非你有明确的流式加载需求。

oxipng -o 4 --strip safe --alpha out.png zopflipng -m --lossy_transparent in.png out.png pngcrush -brute -reduce -rem alla in.png out.png

--strip safe只删那些确认可以安全删除的辅助块，不会误删影响显示的；--alpha会尝试优化全透明像素的 RGB 值（因为透明像素的颜色本来就不可见，统一成同一个值能提高压缩率）。

4.3 各类方案对比与选型表

下面这张表是我在几类典型素材上做的对比，样本是一张 1920×1080 的界面截图、一张 512×512 的扁平图标、一张 800×600 的插画。数据只代表这几类内容的典型量级，不同图片差异会比较大，重点看比例关系。

从表里能看出一个很清晰的结论：量化的收益远大于无损压缩。如果你只愿意做一件事，那就有损量化；如果能接受流程麻烦一点，量化加无损压是性价比最高的组合。

4.4 不同场景下的落地参数

界面截图这类内容，颜色通常是几十到几百种，量化到 128 色基本无感。我常用的参数是--quality=70-90 --speed 1，先看输出体积，如果降幅不够再手动指定色数。要注意截图里如果包含照片缩略图，量化会让那块区域明显变差，这时候要么局部处理，要么整体改成 256 色加抖动。

图标这类内容，往往只有几种颜色，可以直接--quality=0-100让它自己找最优色数，经常能压到十几色还不失真。真正需要小心的是带柔和投影的图标，投影部分是渐变，量化容易出色带，这种情况我会保留 256 色并开启抖动。

插画和线稿是 PNG 的主场，量化效果好，但要留意线条边缘的抗锯齿像素。降色之后抗锯齿的中间色可能被合并，边缘会显得硬。可以适当提高色数到 256，或者改用调色板加局部保留关键色的方式。

长图和超大图要单独说。这类图的问题往往不是体积而是内存，解码需要宽×高×4字节的缓冲区，10000×20000 的图光缓冲就 800MB。我的做法是先确认最终显示尺寸，按显示尺寸的两倍导出，超出的部分直接裁掉，不要指望压缩工具能解决结构性问题。

5. 踩坑实录：透明、缩放、兼容性三大雷区

PNG 用得久了，翻车的地方其实高度集中，就那么几类。我把这些年遇到的和同行反馈过的整理一下，每一条背后都有具体的现象和原因。

5.1 透明背景导出后变黑变白

这是被问得最多的一个问题。现象是：设计稿里明明是透明背景，导出成 PNG 放到网页或者某个软件里，透明区域变成了黑色或者白色。原因通常有两个。

第一个是查看器的背景色。很多图片查看器默认用黑底或者白底渲染透明区域，图片本身没问题，只是看起来像变色了。判断方法是把图拖进浏览器，或者用支持棋盘格背景的工具打开，如果看到棋盘格就说明 Alpha 是好的。

第二个是真出问题了：全透明像素的 RGB 值被清零。PNG 用的是非预乘 Alpha，全透明像素的 RGB 分量理论上不参与显示，但某些工具在合成时会做dst = src * a + bg * (1 - a)的插值，如果缩放或者抗锯齿过程中对透明区域采样，就会把 RGB 为零的黑色混进边缘，导致半透明边缘发黑。反过来如果 RGB 被填成 255，边缘就会发白。

解决办法有两条：一是在导出时不要开启“清理透明像素 RGB”之类的选项；二是如果一个工具已经这么干了，用--alpha参数让优化工具把全透明像素的 RGB 统一设置成边缘颜色，能显著缓解发黑。更根本的办法是在合成时使用预乘 Alpha，把乘法提前做掉，这样插值就不会引入背景色污染。

5.2 缩小图像后的白边与灰边

把一张带透明的 PNG 缩小，边缘出现一圈白边或者灰边，这个问题的根源和上一条同源，但触发路径不同。缩放的本质是对邻域像素加权平均，如果边缘外的那部分像素是透明的黑色，平均之后边缘像素的 RGB 就被拉向黑色；如果是透明的白色，就被拉向白色。

正确的做法是在预乘空间里做缩放：先把 RGB 乘以 Alpha，缩放，再除回去。很多图像库默认在直通空间里缩放，就会出这个问题。如果用的是命令行工具，可以查一下是否有“预乘处理”的开关；如果自己写代码，缩放前手动预乘一下就行。

还有一个容易被忽略的点：伽马。在 sRGB 空间直接做平均，物理上是不对的，因为 sRGB 是非线性的。严格做法是先转到线性空间，缩放，再转回 sRGB。对于对比度高的边缘，这个差异肉眼可见。不过我个人的经验是，大部分界面素材在 sRGB 空间缩放的误差可以接受，真正需要精确的是产品图、缩略图这类会被反复缩放的内容。

5.3 位深、色域与解码器差异

同一张 PNG 在不同地方显示效果不一致，通常和位深、色域、解码器实现有关。

位深方面，16 位 PNG 在浏览器里基本都会被降到 8 位显示，因为屏幕和渲染管线就是 8 位。如果你导出 16 位是为了保留更多层次，那要清楚这个优势只在后续处理链路里存在，最终显示看不到。反过来说，如果只是用于显示，导出 8 位就够了，体积能小一截。

色域方面，带 iCCP 的 PNG 在支持色彩管理的软件里会按配置转换，在不支持的软件里会按 sRGB 直接显示，两者颜色可能差得挺明显。交付给不确定环境使用时，我倾向转成 sRGB 并去掉 iCCP，一致性更好。

解码器差异主要体现在辅助块的宽容度上。比如 CRC 校验失败时，有的解码器直接拒绝，有的跳过继续；遇到未知关键块时，规范要求报错，但有些实现会强行解析。做跨端交付时，最好用严格模式的校验工具过一遍，把不合规的地方提前修掉。

5.4 常见问题速查表

我在模拟项目里把这套排查流程做成了一个脚本，上传素材时自动跑一遍，输出位深、颜色类型、块列表、CRC 结果、估算解码内存，基本能在问题流到下游之前拦住。这套东西写起来不到两百行，收益却很大。

6. 从 PNG 延伸到格式选型：别把一种格式用到死

把 PNG 研究透之后，你会发现真正决定效果的不是“会不会用 PNG”，而是“知不知道该在什么时候不用它”。格式选型的判断维度其实就四个：内容类型、是否需要透明、是否允许有损、目标环境的支持度。这四条一过，答案基本就出来了。

6.1 有损场景该切到什么格式

照片、复杂渐变、大面积纹理，这类的共同特征是高频率细节少、颜色过渡多，正适合基于变换编码的有损格式。选型时我会看两个指标：目标环境支持和压缩效率。新一代格式在同等主观质量下体积优势明显，但兼容性和工具链成熟度要打折；传统格式胜在到处都能开，编码器优化也成熟。

我的务实做法是双轨输出：主体用兼容性最好的有损格式，同时对支持的客户端提供体积更小的新格式，靠能力检测决定加载哪个。这样既不会在老环境上开天窗，也能让新环境拿到收益。要注意的是，多轨输出意味着维护成本翻倍，素材更新时两套都要重新生成，所以一定要把生成流程脚本化，不能靠手工导。

还有一类容易被误判的内容：带文字的截图。很多人觉得截图是“图”，就按照片处理，结果文字边缘糊成一团。截图本质上是高频细节密集的内容，应该走无损或者准无损路线。如果非要压体积，用低色数量化比用有损变换编码效果好得多。

6.2 动图与序列帧的处理路径

动图这块，PNG 的 APNG 扩展确实能用，每一帧按 PNG 压缩，支持透明和 24 位色彩，比传统 256 色的动图格式质量高不少。问题是它的压缩方式决定了体积：每帧独立编码，帧间冗余利用得很有限，一段三秒的动效轻松上到几 MB。

所以在实际项目里，我的判断标准是：帧数少于 20、尺寸小于 400×400、循环播放的简单动效，可以考虑 APNG；一旦超过这个规模，就转成视频编码，用静音循环播放的方式实现，体积能降一个数量级。代价是透明背景支持要看具体编码方式，需要额外的兼容处理。

序列帧是另一个常见需求，比如加载动画、表情包。这类内容如果帧数多、单帧小，与其存成几十张 PNG 再逐张加载，不如打成一张雪碧图，用索引定位播放，请求数和内存占用都能降下来。雪碧图的排布要注意：帧之间留出间距，避免采样时相邻帧串色；整张图的尺寸尽量对齐到 2 的幂次或者工具友好的尺寸，纹理上传效率更好。

6.3 长期存档的格式策略

最后说说存档。做素材库、做设计源文件管理，长期存档的核心诉求是可逆和可解析。可逆意味着解码后的像素必须和原始完全一致，这一点上无损压缩是硬要求，任何有损方案都不适合做源文件。可解析意味着格式要有公开、稳定、无歧义的规范文档，十年后拿到的工具还能正确打开。

从这两个角度看，无损 PNG 是很合适的选择：规范公开、结构清晰、校验完备，即使某个块的 CRC 坏了也能定位到具体位置。我在做长期归档时的具体做法是：源文件保留未量化、未剥离辅助块的原始版本；交付件单独一份；两份用命名规则区分清楚，不要混在一个目录里。归档时顺手记录一下文件的位深、颜色类型、尺寸和解码内存估算，将来批量处理时能省掉大量重复分析。

我个人现在的默认做法是：任何需要透明或者需要保真的素材，先出一份无损 PNG 归档；交付时按场景做量化或者换格式；每次批量处理前，先用校验脚本扫一遍源文件的块结构和 CRC，把异常文件单独拎出来处理。这套流程跑下来，返工次数比以前少了非常多，也很少再出现“压缩之后边缘发黑”这种低级问题。