上线前最后一轮检查，往往最容易把问题翻出来。有人把首页几张产品图统一压了一遍，原图三百多KB，处理完反而快到五百KB，页面加载肉眼可见地变慢。更让人想不通的是，文件属性里分辨率没变，画质看上去也没提升，体积却实打实地涨了。这不是工具出了问题，而是“压缩”这件事从一开始就被当成了单一动作。
先把压缩目标拆开。体积、画质、尺寸是三个独立指标，不是一回事。体积指文件占用的存储空间，画质指压缩后视觉损失的多少，尺寸指图片的像素宽高。很多人把三者混着看，以为“压缩”必然带来“变小”，于是拿到体积变大的结果就反复重试。实际上，当原图本身已经被处理过，或者尺寸远大于展示需要时，某些压缩路径会先解码再重新编码，中间环节反而把数据量加上去了。
核对要按顺序来，跳步容易白忙。第一步看原图尺寸是否远超展示尺寸。一张四千像素宽的照片放进只有八百像素宽的容器里，任何压缩工具都只能在这个大尺寸上做文章，体积自然下不来。先把尺寸降到展示需要的两倍以内，再谈压缩，往往一步就解决问题。
第二步看格式选择是否合适。照片类内容用支持丰富色彩的格式，图标和纯色块用支持透明和锐利边缘的格式，选错格式会让压缩效率大打折扣。把一张色彩丰富的照片存成不适合的格式，体积可能不降反升。
第三步看压缩参数是否被重复处理。有些工具默认开启“优化”，有些编辑器保存时又叠加一层，两次处理叠在一起，等于对同一张图反复编码，体积和画质都受损。核对时确认整条链路只做一次有效压缩。
第四步看是否被二次转码。图片从设计软件导出、经过聊天工具传输、再上传到后台，每一环都可能悄悄转码。转码后的文件已经不是原始数据，再压缩就是在二手数据上做文章。核对时尽量回到最初导出的那份文件。
第五步看是否保留了无用元数据。拍摄设备信息、编辑历史、缩略图缓存都可能藏在文件里，这些数据对网页展示没有价值，却实打实占体积。清理元数据是低成本的减重手段。
据此可以整理一份上线前图片检查清单：尺寸是否接近展示需要的两倍以内；格式是否与内容类型匹配；体积是否小于原图且符合页面预算；清晰度在目标设备上是否可接受；透明通道是否被正确保留；缩略图是否单独生成而非直接缩放主图。六项逐一过一遍，比反复点压缩按钮有效得多。
有些情况需要重新导出而不是继续压。原图已经被多次转码、透明通道出现杂边、文字边缘发虚、色彩明显偏移，这些都说明文件本身已经受损，继续压缩只会放大问题。正确做法是回到设计源文件，按目标尺寸和格式重新导出一次。it数运在网站维护中处理这类问题，通常先确认素材来源和展示位置，再决定是重新导出还是调整参数，而不是在已经变形的文件上反复尝试。
真正省事的做法是把功夫花在入库环节。建立素材入库规范：统一命名、标注用途和展示尺寸、保留原始导出文件、单独存放网页版本。素材一进库就是干净的，上线前只需核对，不必救火。压缩不是越压越小，而是在正确的尺寸和格式上做一次干净的处理。
