如果上传限制是 100 KiB，应该把 PNG 换成 JPEG，还是先缩小？这次把一张带小字、细线、表格和渐变的自有示意图做成五个文件。先看结果，再决定哪种代价可以接受。
原尺寸 PNG 为 273.8 KiB，同尺寸 JPEG 0.82 为 85.6 KiB，已经低于 100 KiB。把图片缩到 960 × 600 后，PNG 仍有 124.4 KiB；缩小不等于一定满足体积限制。这些数值只适用于本次素材。
原图是什么，想保留什么？
原图是本站绘制的界面示意素材，不是其他产品的截图。尺寸为 1440 × 900，包含 16–32 像素的英文、1 像素细线、平涂色块和渐变。我们关心的是小字在最终显示时能否读清，而不只是字节数更小。可以下载 完整原图 PNG ↓，也可以查看可编辑 SVG 源文件。
把“缩尺寸”和“换编码”分开测试
- 保留原图，先在 1440 × 900 下分别导出 PNG 和 JPEG，JPEG 质量参数设为 0.82。这样能比较不改变像素尺寸时的编码差异。
- 另从原图生成 960 × 600：宽高都乘以 2/3，避免只改一边造成形变。分别导出 PNG、JPEG 0.82、JPEG 0.35。
- 重新打开每份成品，检查实际宽高和字节数。两个尺寸的文件不能直接用像素差判断画质，因此每份成品都只与自己的导出前画布比较。
- 点击下方图片在新页面查看原始文件，按 100% 显示检查底部小字和表格细线。网页缩略图会改变显示倍率，不能单独用来下结论。
| 下载文件 | 像素尺寸 | 文件字节 | 平均 RGB 绝对差 |
|---|---|---|---|
| screen-full.png ↓ | 1440 × 900 | 280,371 | 0 |
| screen-full-82.jpg ↓ | 1440 × 900 | 87,669 | 0.7526 |
| screen-small.png ↓ | 960 × 600 | 127,359 | 0 |
| screen-small-82.jpg ↓ | 960 × 600 | 55,189 | 0.9682 |
| screen-small-35.jpg ↓ | 960 × 600 | 30,263 | 2.2151 |
怎样选一份用于发布的成品？
本次如果只要求“原尺寸、低于 100 KiB”，同尺寸 JPEG 0.82 满足体积条件，但仍需接受小字边缘的有损变化。如果平台只显示 960 像素宽，960 × 600 JPEG 0.82 可再减少体积。若要让读者放大核对细字，保留较大的 PNG 下载版本比一味压缩更合适。
0.35 的 JPEG 在本例中比 0.82 更小，平均颜色变化也更大。但不能把“变化更大”直接解释为所有区域都更难读，更不能把一次结果推成“截图必须用 PNG”。读者实际阅读的字、线和数值，才是最终检查对象。
看到文件变大，先查这三件事
- 原文件可能已经压缩得很好。重新转 PNG 或高质量 JPEG，可能反而更大。
- 不要只修改文件扩展名。需要真正重新编码，并重新打开成品确认格式。
- “质量 82”不是“保留 82% 细节”，也不保证所有照片或截图得到相同压缩比。
你可以在尺寸与格式工具里加载这张原图，先保留 1440 × 900 选择 JPEG 82，再尝试 960 × 600；工具显示每次实际生成的字节数。输入变化后需要重新生成，不会把旧结果当作新参数的成品。
这组数据怎样得到？
2026 年 11 月 5 日，本站在 Windows 的 Chromium 156 浏览器中，用 Canvas 2D 绘制自有 SVG，再通过 canvas.toBlob() 导出。JPEG 的 0.82、0.35 是浏览器编码参数，不是通用画质分数；不同浏览器和版本可能生成不同字节数。所有文件均可下载，完整测量记录包含尺寸、文件体积和生成环境。
平均 RGB 绝对差的计算方式为：把编码文件重新解码，与相同尺寸、相同背景的导出前画布逐像素比较三个颜色通道，求绝对差平均值，取值范围为 0–255。它仅描述本组文件的编码变化，不代表视觉质量分数，也不能证明缩小图片没有损失信息。透明像素的不可见 RGB 不适合与不透明底图作直接质量比较。
下一步：阅读PNG 与 JPEG 的用途选择，或检查下一篇的透明背景问题。