1. 从一张花屏的图说起PNG编解码到底在解什么有次我在嵌入式设备上调一个图片显示问题背景图在PC上打开一切正常烧进设备屏幕后整幅画面像被什么东西“横向撕碎”了颜色错位、出现周期性条纹。一开始怀疑是LCD驱动初始化不对查了一圈发现裸BMP显示完全正常问题只出在PNG上。后来定位到是解码流程里少做了一步“滤波还原”直接把zlib解压出来的原始数据扔给了显示层。那一刻我才意识到很多人对PNG的理解停留在“无损压缩格式”这六个字上但真正上手写编解码时PNG的设计远比想象中精巧。PNG编解码不是单纯的压缩解压它是一条完整的像素还原管线编码端要先把原始像素做一种叫“滤波”的预处理再用zlib压缩解码端则反过来先解压再按行做逆滤波最终才能拼回一张和原始图像逐字节一致的位图。这也是PNG作为无损格式的核心底线——哪怕中间的滤波因子差了一个字节输出图就会出现肉眼可见的瑕疵而这种瑕疵往往是“难以用网络传输、难以调试、只在特定图像内容下出现”的隐藏雷。这篇文章写给三类人想手写PNG解析器或者嵌入式移植的开发者做图像处理但一直把PNG当黑盒的软件工程师以及在项目里被PNG兼容性问题折磨过的朋友。我会从文件结构、滤波原理、隔行扫描、编码决策到常见排查经验把PNG编解码这条链路从头到尾拆开讲清楚不涉及框架源码全部用最基础的C语言风格逻辑来表达保证你看完能自己照着实现一个可用版本。2. 先看PNG的物理骨架chunk不是可选项是理解一切的基础PNG文件结构不复杂但它的设计哲学和BMP、JPEG完全不同。BMP是“按文件头像素矩阵直接读”JPEG是“按段marker segment组织压缩流”PNG则是一个纯粹的“chunk数据块链”。整个文件从第一个字节到最后一个字节都遵循一个统一的格式8字节签名后面跟着一条由若干个chunk组成的数据流。2.1 固定签名与chunk的通用四段式PNG的前8个字节是固定的十六进制序列89 50 4E 47 0D 0A 1A 0A翻译成ASCII就是\x89PNG\r\n\x1a\n。开头那个0x89是刻意的——它不在普通文本编码的打印范围内用来让旧系统识别出“这是个二进制文件”。后面的0x0D 0x0A和0x1A则是为了在某些老操作系统中防止文件被错误处理。这个签名不需要解释直接比对校验就行。签名之后就是chunk序列。每一个chunk都严格遵循四段式结构字段长度说明Length4字节大端当前chunk数据区的字节数不含长度本身、类型和CRCChunk Type4字节大写的ASCII字母标识chunk类型Chunk Data可变实际内容CRC4字节对“Chunk Type Chunk Data”做的CRC-32校验这里有几个容易踩的坑。CRC的计算范围是“类型数据”不是“长度类型数据”。新手最容易犯错的就是把Length也算进去导致明明文件正常自研解码器却一直报CRC错误。另一个细节是所有多字节字段都是大端序网络字节序如果你在x86机器上直接memcpy读出4字节再强转int数值会完全错乱必须手动做(b0 24) | (b1 16) | (b2 8) | b3这样的拼接。2.2 关键chunkIHDR、IDAT、IEND以及它们的严格顺序不夸张地说PNG文件的可读性核心就集中在IHDR上。它是文件的第一个chunk数据区长度固定为13字节按顺序包含图像宽度4字节图像高度4字节位深Bit Depth1字节合法值为1、2、4、8、16颜色类型Color Type1字节合法值为0、2、3、4、6压缩方法1字节目前必须为0表示zlib/deflate滤波方法1字节目前必须为0隔行扫描方式1字节0表示非隔行1表示Adam7隔行颜色类型决定了解码时每一像素携带多少个通道channel这是整个PNG编解码里最容易混淆的映射关系颜色类型值含义通道构成每个像素占用0灰度图1个灰度通道位深/8 字节2RGB真彩图R、G、B三个通道3 × 位深/8 字节3调色板索引图1个索引通道位深/8 字节4灰度Alpha灰度、Alpha两个通道2 × 位深/8 字节6RGBA真彩AlphaR、G、B、A四个通道4 × 位深/8 字节IDAT chunk承载的是经过压缩的实际图像数据但有个非常关键的细节文件里可能出现多个IDAT块解码时必须把它们的数据区按顺序拼接成一个连续的大缓冲再丢给inflate解压。你不能每遇到一个IDAT就单独解压一次。zlib解压器天然支持流式输入正确做法是把所有IDAT数据连起来后一次性解压输出缓冲长度可以直接用IHDR算出来解压后字节数 height × (1 width × channels × bitDepth / 8)等号右边每行开头的“1”代表每个扫描线scanline的第一个字节用来记录这一行用了哪种滤波类型。IEND是文件结束标记数据区为空只起到终止作用。我建议初学实现时先用十六进制编辑器找一个简单的PNG文件对照观察先读签名再循环解析chunk遇到IHDR就记录宽高和颜色类型遇到IDAT就累加数据遇到IEND就停止。把这一步跑通了PNG解析的骨架就立住了。3. 解码核心链路zlib解压之后真正的活儿才刚开始如果你只做“解压→显示”这一步那你只是在处理一个巧合能看懂的文件。PNG在zlib压缩之前做过一层与图像内容强关联的预处理——滤波Filtering。这层处理不是加密也不是有损变换而是对每一条扫描线的字节做“像素差分编码”目的是让进入压缩器的数据相关性更强、熵更低从而显著提升压缩率。解码端必须严格逆着编码端走先把IDAT拼起来、inflate解压、拿到完整的滤波后数据流然后从头到尾逐行做逆滤波unfilter才能得到真正的扫描线像素数据。3.1 inflate之后的内存布局长什么样把IDAT拼接、解压后的数据视为一个大字节数组。这个数组的物理组织方式是第1行 [滤波类型字节] [第1行全部通道的滤波后数据]第2行 [滤波类型字节] [第2行全部通道的滤波后数据]...第height行 [滤波类型字节] [第height行全部通道的滤波后数据]每一行的滤波类型字节是0~4之间的整数代表这一行用的是五种滤波模式中的哪一种。不同行可以用不同滤波解码时每一行都要独立读取这个类型值再独立还原。常见的错误是把第一行的滤波类型当成全图像的公共参数后面的行都套用同一种还原结果就是图像末尾区域花掉。3.2 逆滤波的“像素级流水线”逆滤波是按“通道样本”为单位的不是按像素。这跟很多人直觉里的“按像素处理RGB”不一样。举个例子一张8位RGB图每个像素占3字节解码时第一个字节是R第二个是G第三个是B。滤波和逆滤波作用于这些独立的字节序列上而不是把RGB当成一个整体。对每一条扫描线从左到右遍历每一个字节处理当前字节时要用到Recon(x)当前目标字节的还原值Raw(x)滤波后数据流中当前字节的原始值Left当前行左侧相邻通道的还原值对行首字节Left为0Up上一行同一列通道的还原值对第一行Up为0UpLeft上一行左侧相邻通道的还原值对第一行或行首为0我用一个简化但逻辑完整的C风格代码展示逆滤波的骨架uint8_t unfilter_byte(uint8_t filter, uint8_t raw, uint8_t left, uint8_t up, uint8_t upleft) { switch (filter) { case 0: return raw; // None case 1: return raw left; // Sub case 2: return raw up; // Up case 3: return raw (left up) / 2; // Average case 4: return raw paeth_predictor(left, up, upleft); // Paeth default: return raw; // 非法类型按None处理但应该报错 } }这里所有算术都在uint8_t范围内自然溢出等价于模256运算不要用int去存然后追加取模直接让无符号整型截断就行这是PNG规范定义的做法也是解码器和编码器能对齐的数学基础。paeth_predictor的逻辑如下uint8_t paeth_predictor(uint8_t left, uint8_t up, uint8_t upleft) { int p (int)left up - upleft; // 初始预测值 int pa abs(p - (int)left); int pb abs(p - (int)up); int pc abs(p - (int)upleft); if (pa pb pa pc) return left; if (pb pc) return up; return upleft; }这段代码网上到处都是但很多人没注意到的是Paeth预测不是简单取“相邻像素均值”而是通过三个候选方向选择一个与线性模型预测值最近的邻居。它在处理图像中的斜向边缘时效果明显优于平均滤波。理解了这个“为什么”你才能在遇到滤波类型分布异常时知道怎么判断。整个解码过程必须“逐行、逐字节、从左到右”地推进因为它依赖当前行左边的重建值和上一行同列的重建值。这个串行依赖是解码性能的主要瓶颈。3.3 一个可以自测的边界案例写代码时建议用一张4×4的灰度PNG做单元测试。灰度图只有一个通道bpp每像素字节数固定为1边界条件更容易手算。第一行的Up和UpLeft都是0每行第一个字节的Left是0。如果这行用了Sub滤波那么这一整行的还原数据不是“原始字节”而是“当前字节前一个还原字节”的递推和。你把数据流打印出来对照手算很快就能发现代码里哪里少加了。我还遇到过一种隐蔽的Bug多通道图里按像素处理而不是按通道处理。比如一个8位RGBA图如果代码错误地认为Left是“前一个像素的A通道值”而不是“前一个通道的R或G或B值”整幅图的颜色会整体偏色而且行越靠右偏得越严重。这种问题光看局部像素根本看不出规律必须回到定义上纠正。4. 五种滤波模式逐个拆解None、Sub、Up、Average、Paeth很多人问同一个问题既然PNG号称无损压缩为什么在zlib之前还要多此一举做个滤波答案是无损压缩的极限取决于数据熵而自然图像相邻像素之间的差值往往远小于像素本身的数值范围。把“像素值”变成“像素差值”数据的统计分布会更集中zlib/deflate的LZ77Huffman组合能得到高得多的压缩率。4.1 五种模式的行为差异与适用内容滤波类型预测规则逆变换规则适合场景0 None不处理Raw Raw噪声图、无空间相关性的数据1 Sub用左侧像素预测Raw Left水平渐变、梯度平滑的图像2 Up用上方像素预测Raw Up垂直渐变、扫描行高度相似的图像3 Average同时参考左、上像素均值Raw (Left Up)/2双向渐变的自然图像4 Paeth三方向选择最优邻值Raw paeth_predictor(Left, Up, UpLeft)边缘明显的图形、文字、UI素材单独看公式只是背概念真正理解要落到实际编码器选型上。libpng默认的“自适应滤波”会对一行数据分别尝试五种滤波模式计算滤波后的字节绝对值和Sum of Absolute DifferencesSAD选绝对值之和最小的那种模式写入该行的第一个字节。比如一行深色渐变区域的像素值高平均滤波能把大数值变成小差值压缩器处理起来就省事。反之如果一张图是纯随机噪声任何预测反而会“帮倒忙”此时Filter 0None效果最好硬套Sub反而会扩大数值范围。4.2 bpp对Sub和Average滤波的隐性约束这是PNG滤波里最容易被忽视的细节滤波计算的“左邻参考值”并不是左侧像素的起始字节而是“当前通道的前一个通道值”也就是说单位是单个通道样本不是整个像素。但Sub滤波的原始定义里有一个“bpp每像素字节数”的概念在PNG规范中对Sub滤波的编码公式是Sub(x) Raw(x) - Raw(x - bpp)也就是对当前通道字节用“同通道在上一像素位置的还原值”做预测而不是简单地用紧挨着的左边字节。解码时则是Recon(x) Raw(x) Recon(x - bpp)对于bpp1的灰度图这等价于“用左边紧邻字节”但对于bpp4的RGBA图实际上是“用当前通道的前一个像素值”。如果代码直接用x-1而不是x-bpp通常表现是图像左侧部分正常越往右颜色偏移越严重甚至出现类似“色彩撕裂”的效果。这是很多从零实现PNG解码的开发者最容易卡住的地方。Average滤波也是同理编码公式里的(Raw(x-bpp) Up(x))/2中的左边参考项必须用“x-bpp”位置的还原值而不是x-1。只有Paeth滤波由于要同时评估左、上、左上三个方向内部对左边参考的选取同样需要区分bpp。但是Paeth上下文的“UpLeft”指的是“上一行同通道、当前列”的还原值还是“上一行同通道、上一像素位置”的还原值这里不同实现有微小差异严格按规范走即可Predictor的输入是Recon(x-bpp)、Recon(x)上方同列、Recon(x-bpp)上一行同列。4.3 滤波类型不等于压缩质量动态选择才是核心有些简化实现直接给所有行统一用Filter 1Sub理由是自然图像水平方向相关性最强。测下来压缩率通常不会太差但遇到照片中的天空渐变区域、带Alpha通道的UI切图、纯色大块背景时动态滤波可以再省10%~30%的体积。反过来编码器如果对每行都做5次完整滤波尝试CPU开销会显著上升所以嵌入式设备上做PNG编码时常常退化为“按行粗粒度选择前几行算一遍五种模式的SAD局部最优决定后续一段行的滤波类型”。解码器不需要关心编码器用的是动态还是固定策略因为每一行的滤波类型都写在该行的第一个字节里只管照着还原就行。5. Adam7隔行扫描小图预览背后的解码复杂度PNG的第二大主题也是最容易劝退初学者的是Adam7隔行扫描。非隔行PNG的解码就是上面章节讲的流程逐行还原、拼成完整矩阵。但隔行PNG会把一张图拆成7个“pass”每个pass只包含部分像素解码后还要做一个“重新交错合并”的步骤。5.1 Adam7的七次扫描规律Adam7之所以叫Adam7是因为Adam M. Costello在1996年提出了这种7遍扫描算法。它的核心思想是先快速传输一个缩略图再逐步填充细节在网络图片加载场景下用户体验更平滑。它的布局规则如下表Pass起始行行步长起始列列步长10808208483480440424524026021271201每个pass内部的数据组织方式和普通PNG完全一样每一行有1字节滤波类型N字节滤波数据。只不过这里的“宽度”不是整图宽度而是“该pass实际包含的像素列数”“高度”同理是“该pass实际包含的像素行数”。解码每个pass时宽度按ceil((width - start_col) / step_col)计算高度按ceil((height - start_row) / step_row)计算。5.2 解码隔行PNG的正确顺序处理隔行PNG最容易犯的错误是“按pass顺序一行一行直接写入最终图像矩阵”。实际流程是对7个pass分别做一套完整的“inflate子数据逆滤波”流程得到每个pass的已还原像素数据。每个pass的数据长度不是固定的需要根据上面的宽度公式动态计算。把pass内每个像素按坐标映射回最终大图的位置。例如pass 1的(0,0)像素放在最终图像的(0,0)pass 2的(0,0)放在最终图像的(4,0)依此类推。所有pass的像素位置不会互相重叠所以最终图像矩阵的每个像素只会被写入一次。如果只对第一个pass做了解码就去显示会出现“图片只显示1/64像素密度”的怪异效果——这就是隔行PNG的“预览层”。处理隔行图时注意内存分配和写入坐标的换算错误非常常见建议写一段独立的“坐标映射函数”做单元测试// 计算某个pass内第i行第j列的像素应放到最终图像的哪个坐标 pass_x start_col[pass] j * step_col[pass]; pass_y start_row[pass] i * step_row[pass];到这里你会发现Adam7的解码过程天然是多趟扫描的不能像非隔行一样只维护“上一行”的上下文每一趟pass的第一行Up都为0所以内存和处理逻辑都更繁琐。很多库甚至直接选择“不支持或慢速支持”隔行PNG这不是没有原因的。5.3 项目里的取舍什么时候必须处理Adam7如果你在写CMS、图片上传服务、电商后端建议直接拒绝隔行PNG或统一转成非隔行再入库因为大部分用户上传的图片用隔行扫描的比例极低。但如果你是写聊天软件、图片浏览器、网页图片解码Adam7必须完整支持因为很多第三方图片压缩工具默认导出的就是隔行PNG。判断一个PNG是否是隔行扫描只用看IHDR数据区的第13字节interlace method字段0是非隔行1是Adam7隔行。拿到这个值以后解析器最好在早期就分流不要用同一套代码硬跑减少后期莫名其妙的“像素丢了一半”问题。6. 编码端的关键决策滤波策略与压缩级别之间怎么权衡解码讲透了编码其实就清晰了编码是解码的镜像过程。但编码器面临一个解码器没有的问题——选择。解码器不管行滤波类型是什么都机械地逆变换。编码器则要在“生成哪种滤波模式”“用什么压缩级别”“是否开隔行”之间做决策这直接决定了输出体积和编码耗时。6.1 滤波选择的“成本函数”与它为什么有效标准做法是对每一行试算5种滤波模式把每种模式产生的“滤波后字节流”的绝对值之和当作成本选成本最低的一种作为该行的滤波类型。这里的直觉是滤波后数值越小且越集中deflate的熵编码收益越大。SAD用绝对值之和作为代理指标计算简单和最终压缩率高度相关所以libpng和大部分工具都用它。真正工程实现里有些优化版本还会考虑Huffman编码的符号分布比如统计滤波后字节的直方图再估算熵但这在嵌入式场景中性价比不高。需要注意这种“试算”需要对每个候选模式都算一遍整行的滤波结果计算量不小。如果只是做类似“PNG转其他格式”的工具还好但如果你在摄像头采集端实时做PNG编码建议用轻量启发式替代完整SAD试算例如统计上一行的平均差分如果很小当前行优先用Up。统计当前行水平方向相邻字节差的绝对值如果远小于垂直方向差分用Sub。遇到前一行和当前行差异性都很小的大色块区域直接Filter 0。6.2 zlib压缩级别与体积的权衡PNG的压缩阶段使用的是zlib的deflate算法压缩级别从0到9。级别0不压缩只是把滤波后的数据原封不动打包级别1速度最快但压缩率最低级别9压缩率最高但耗时暴涨。实际测试中级别6到8的体积差通常只有1%到3%但编码耗时的差距可能在2倍以上。如果你在写服务端转码服务我建议默认级别6遇到超大图比如8000×8000以上甚至可以考虑降级到3或者4因为大图的滤波已经解决了大部分冗余deflate追加的收益很有限CPU时间反而花得不值。如果是嵌入式端做缩略图用级别1即可。6.3 调色板PNGColor Type 3的编码特殊性调色板PNG和前面讲的真彩图有个很大的不同它的IDAT里存的是每个像素的“调色板索引”索引本身是1到4位的整数而不是8位的通道值。解码时需要通过PLTE chunk把索引映射成RGB再通过可选的tRNS chunk获取每个索引对应的透明值。编码调色板类的PNG核心就是两步颜色量化通常用中位切分或八叉树算法和调色板生成。这个量化过程本身是有损的所以严格来说只有“已经在索引空间里的图”比如从GIF转换才能做到无损。量化质量直接决定最终视觉效果。如果原图是渐变丰富的照片调色板设成256色往往能看到明显色带这时要么提高颜色深度要么放弃调色板模式改用RGBA。7. 实战排障PNG解码最容易踩的六个坑不管你是从零写解析器还是嵌入式平台上集成一个现有库下面这些坑我都踩过而且每一次排查都花了不少时间。7.1 CRC校验失败但图片能显示CRC计算范围是“Chunk Type Chunk Data”不包括Length字段。如果你的自定义解析器CRC一直报错先检查是否多算了4字节的长度。另一个常见原因是字节序PNG里所有多字节字段都是大端CRC-32结果在文件里也是大端存储实现时注意把计算出来的值和文件中存储的4字节逐字节比较而不是直接强转int比较。7.2 宽高值为0或超大导致内存崩溃恶意的或者损坏的PNG可能在IHDR里写一个超大的width/height比如65535×65535。解析器如果不做上限检查直接给 IDAT 分配解压缓冲轻则内存暴涨重则直接OOM。成熟的实现都会先校验宽高乘积在合理范围内并且IHDR声明的大小要和IDAT实际解压出来的数据规模匹配实际解压字节数 ! height × (1 width × channels × bitDepth / 8)出现不匹配直接判定文件损坏不要尝试继续解出部分边角。7.3 位深16的灰度/彩色图的显示问题PNG支持16位位深很多主流的图像库和浏览器都能解码但不少嵌入式平台的2D加速器只支持8位。如果你在低端设备上解码16位PNG必须自己做一个高位到8位的换算。注意是“除以257”因为8位最大值255对应16位最大值65535255 65535/257不是简单地右移8位。右移8位虽然视觉差异不大但严格来说会偏暗一两个灰度级做图像对比测试时会暴露。7.4 Alpha通道被丢弃导致四周发黑很多解码器默认只输出RGB把Alpha通道丢掉。如果是盖在网页上的PNG丢Alpha会导致本应透明的区域全部显示成黑色或白色。解决方式是在解码流程里把需要透明信息的场景单独保留tRNS或全通道Alpha输出RGBA格式给渲染层不要在解码器内部提前裁掉。7.5 隔行扫描解码出现“图案错位”Adam7处理中最典型的错误是pass内宽度和高度公式搞错。比如整图宽100像素pass 2的起始列是4、步长8那么这个pass含有的像素列数为ceil((100 - 4) / 8) 12而不是13、也不是11。如果用错了公式后续行的偏移全乱图像呈现明显的“水平和垂直方向双重周期性错位”——这也是我最早遇到的那种花屏现象的一个常见来源。7.6 多个IDAT块的数据顺序在文件读取层面IDAT可能被多次分包正确的做法是全部收集完成后按顺序简拼接。如果每遇到一个IDAT就调用一次inflate很多zlib状态机实现会直接报错或只解出第一块的数据图像只有上半部分。调试时先打印IDAT的总字节数和实际zlib压缩流的长度是否一致可以快速定位是不是拼接遗漏了。8. 进一步优化从“能用”到“跑得快”把PNG编解码跑通之后你会立刻遇到性能瓶颈。对于一张4000×3000的照片非隔行解码的逆滤波步骤是严格的串行流程——当前像素依赖左边和上方的结果不能像JPEG那样按块并行。这是PNG解码比JPEG慢的先天原因。8.1 访存局部性与行缓冲设计逆滤波的最小遍历单元是“通道字节”一次要同时持有当前行已还原数据和上一行已还原数据。内存分配建议直接分配两行缓冲prev_line和curr_line每处理完一行就交换指针不要每行重新malloc。对于RGBA图每个通道连续排列访问模式天然是线性的缓存友好度很高。真正拖慢速度的是Paeth那套比较分支它在每一行的每个字节上都要做一次三方向判断。8.2 SIMD加速的空间现代ARM和x86 CPU都支持SIMD指令理论上可以同时处理16个甚至更多字节的逆滤波。但实际落地时会发现Sub滤波有跨bpp的递归依赖不能直接并行Up滤波没有递归依赖可以向量化Average滤波中(left up) / 2的读取依赖横跨相邻通道向量化难度中等Paeth则因为每字节的判断分支不同向量化比较棘手。一个工程上可行的折中先判断整行的滤波类型如果是None或Up直接用宽SIMD路径处理Sub和Average使用标量路径Paeth用带分支的标量路径。这种“类型分派”的优化往往能让解码速度提升30%到50%。8.3 要不要自己造轮子如果你是商业项目我不建议从头实现。libpng、stb_image、lodepng都是成熟选择。stb_image单文件、易集成适合快速预览libpng功能全但API古老抽象lodepng代码清晰、适合学习和裁剪。但自己写一遍的价值在于你能真正理解PNG的滤波思想和chunk流设计遇到第三方库的兼容性Bug时能快速定位是“库的问题”还是“文件的问题”。我个人建议喜欢折腾的开发者至少用lodepng通读一遍源码再考虑要不要自己维护一个精简版。8.4 特殊场景PNG帧序列与视频编解码标题相关的热搜词里“视频编解码”和“PNG帧序列”经常一起出现。不少人拿PNG当无损视频中间格式用因为它能保证每一帧像素级无损。但PNG没有帧间压缩体积膨胀非常严重。如果你真的需要用PNG保存视频帧要注意两点所有帧的宽高和颜色类型保持一致否则后期合成视频时会出现无法对齐的坑帧号命名规范必须足够健壮建议用frame_000001.png这种固定位数的命名方式避免排序时“frame_2.png”排在“frame_10.png”后面的经典错误。9. 写在最后一个多年后回头看才明白的小经验最后分享一个实际经验。有段时间我在一个下载服务里做图片校验文件动不动就是几万张PNG既要快速解码又要防止恶意文件把服务打崩。最初方案是直接调libpng一把梭什么都能解但偶尔会出现“某些文件在其他库里打开没问题在我服务里就失败”的情况。后来不纠结于库而是花了一个晚上自己写了个极简解析器专门输出IHDR信息、chunk列表、CRC检验结果、每一行的滤波类型分布。有了这层地毯式扫描绝大多数非法文件一眼就能看出来是哪个字段在作妖。PNG本身不是一个多复杂的格式它的复杂之处藏在“像素无关的细节”里大端字节序、CRC范围、bpp引起的参考像素偏移、Adam7的7趟映射、zlib的流式拼接。这些细节单独看都不难但凑在一起时任何一个环节出错最终结果都可能是一张让你调试到怀疑人生的花屏图。如果你把上面这些知识点逐一在自己的代码里验证过一遍以后再遇到PNG相关的诡异问题基本都能在三步之内定位到根因。