拓冰网站定制 
国庆这天祝祖国生日快乐。放假前这几天我一直在改自己一个小工具站的图片上传逻辑。原来那套写法是用户传什么图前端都先画到 canvas 上再用 toBlob 统一转成质量 0.9 的 JPEG 传给后端。当初这么定是图算账方便格式统一以后后端只用存一种文件。我也一直默认 JPEG 就是最省空间的那个格式。这回拿一张红底海报去测才发现这条规矩在这类图上是反着来的。测试用的海报是我用脚本画的 1600×900 促销风平面图。红底上方横着一行黄色的大标题。下面那块白卡上是红字边上摆着同样字号的黑字当对照。原图是 126 373 字节的 PNG大概 123 KB。测试机是一台 Apple M4 / 16 GB 的 Mac。导出走的是 Chromium 149 的开源构建。按原来的逻辑转成 JPEG 0.9 以后出来 157 626 字节154 KB。文件比原图还大。放大五倍一看红字边上还多出了一圈发脏的晕边。我本来是想省空间的结果这张图存下来更占地方也更难看。我的第一反应是 0.9 这个质量给低了。于是我在同一台机器上把 0.8、0.9、0.95、0.99 和 1.0 这几档都测了一遍。0.8 出来 120 501 字节只比原图小一点点字边却是这几档里最脏的。质量拉到 0.99 的时候出来 270 978 字节。体积是 0.8 的 2.25 倍字边也没干净多少。脏不脏我量的是字边一圈像素和原图之间的平均色差这个数叫 ΔE。0.8 这一档是 8.11拉到 0.99 还剩 6.35。通常的说法是 ΔE 到 5 以上就是一眼能看出来的色边。只有拉到 1.0 这一档才突然干净ΔE 一下掉到了 0.19。可文件也涨到了 438 482 字节是原图的 3.5 倍。为一张海报存 428 KB 的文件我那台小服务器的硬盘先不答应。1.0 为什么会一下子变好我去读了 JPEG 文件头里记着的采样因子才弄明白。0.99 及以下导出的 JPEG 全是 4:2:0 抽样颜色信息在横竖两个方向上各砍掉一半。到 1.0 才换成颜色一点不砍的 4:4:4。红字和底色的区别大半落在颜色上面颜色一砍字边就晕开了。在 Chromium 里一直往上调质量等于在已经砍过颜色的图上继续花钱。把这几档摆在一起算账就更清楚了。从 0.8 拉到 0.99 多花了 150 KB 却只让字边色差少了 1.76。反倒是我原来看不上的两个选项最干净。124 色的 PNG-8 是 48 481 字节WebP 无损是 49 432 字节。两个的色差都贴着零体积也比哪一档 JPEG 都小。这句话有个前提。它只对这种几种纯色加字的平面图成立换一类图就不一定了。我怕自己画的图太规整又从网上找了一张现成的 2026 年国庆放假通知模板来试。模板出自稿定设计尺寸 1242×2688原图 PNG 是 3 339 216 字节。质量这条线的方向和我那张海报一样。浏览器 JPEG 质量从 0.80 提到 0.99文件变成原来的 3.2 倍。「假期安排」这几个红字的字边色差只是从 6.56 落到 4.48。到 1.00 才换成 4:4:4这时文件是比原图 PNG 还大的 3 643 511 字节。PNG 这一头在这张图上却不占便宜。模板里有渐变、插画和灯笼。它存成 WebP 无损是 2 359 014 字节比 JPEG 0.9 大了 2.5 倍。这张是我拿那张模板在自己写的一个导出对比小页面上截的整屏。页面顶上选的是 JPEG、质量 0.99、放大 6 倍。上半块是原图。下半块是把导出的文件重新解码以后的同一块区域。放大的都是卡片上「10月8日返岗」那一行红字。导出后那块右上角写的 1.91 MB 和抽样 4:2:0 是页面自己从文件头里读出来的。要看的是笔画外沿。原图的红字边是齐的导出后每一笔外面都贴着一圈淡粉色的晕「日」和「岗」的横竖笔画边上最明显。这行字有 40 像素左右大差别得细看。模板日历上更小的农历字放大 6 倍以后在 JPEG 0.9 那份里能看出发暗发褐。我还想知道现成的工具碰到这张图会怎么处理。对照组我用的是图映 ImgInghttps://imging.cn/的压缩转换同一台 Mac 和同一个 Chromium 下全默认参数跑的全程也没看到上传请求。它默认根本没给我 JPEG。界面提示检测到图标或线稿以后直接走了 PNG-8结果是 124 色的 48 481 字节旁边标着省 62%。我又手动把下载格式切到 JPG 看看它会怎么说。它推荐的质量是 88出来 147 563 字节下面还跟着一行提醒说比原图大 17% 想更小可以换 WEBP。把滑杆拉到 100 出来的是 270 978 字节和我自己用 toBlob 0.99 导出的是同一个文件逐字节一样。也就是说在 Chromium 里它导出的 JPG 同样是 4:2:0。工具能做的是提前提醒你这张图别转 JPG转完以后的色边它也救不回来。省 62% 这个数也只是那张程序海报的结果。网上那张模板丢进去以后它判的是截图或界面。它默认走 WebP 画质 843.18 MB 变成 587.9 KB 标着省 82%。字边色差是 5.12和有损 WebP 在一个水平上。回头算账。一律转 JPEG 在照片上到底省不省钱我这次没测照片不好下结论。在这张红底海报上它是纯亏的。存储多占一截每次被访问还要多走一截流量。图还更难看。我那个站偶尔会有人传活动海报和带字的宣传图这部分一直在白白多花钱。测到 1.0 那档的时候手边那杯口粮茶已经凉透了。我现在的改法是转格式之前先判断图是哪一类。颜色少、大块纯色加字的图保留 PNG 或者减色成 PNG-8剩下的才转 JPEG。判断的门槛我还在调。照片那一侧我还没测过这条线定在哪我心里也没底。你的上传逻辑要是也写死了转 JPEG可以拿一张红底白字的图过一遍。先对比转出来的字节数和原图再放大到五六倍看字边有没有晕开。 上传图片一律转JPEG，红底海报就遭殃了
国庆这天祝祖国生日快乐。放假前这几天我一直在改自己一个小工具站的图片上传逻辑。原来那套写法是用户传什么图前端都先画到 canvas 上再用 toBlob 统一转成质量 0.9 的 JPEG 传给后端。当初这么定是图算账方便格式统一以后后端只用存一种文件。我也一直默认 JPEG 就是最省空间的那个格式。这回拿一张红底海报去测才发现这条规矩在这类图上是反着来的。测试用的海报是我用脚本画的 1600×900 促销风平面图。红底上方横着一行黄色的大标题。下面那块白卡上是红字边上摆着同样字号的黑字当对照。原图是 126 373 字节的 PNG大概 123 KB。测试机是一台 Apple M4 / 16 GB 的 Mac。导出走的是 Chromium 149 的开源构建。按原来的逻辑转成 JPEG 0.9 以后出来 157 626 字节154 KB。文件比原图还大。放大五倍一看红字边上还多出了一圈发脏的晕边。我本来是想省空间的结果这张图存下来更占地方也更难看。我的第一反应是 0.9 这个质量给低了。于是我在同一台机器上把 0.8、0.9、0.95、0.99 和 1.0 这几档都测了一遍。0.8 出来 120 501 字节只比原图小一点点字边却是这几档里最脏的。质量拉到 0.99 的时候出来 270 978 字节。体积是 0.8 的 2.25 倍字边也没干净多少。脏不脏我量的是字边一圈像素和原图之间的平均色差这个数叫 ΔE。0.8 这一档是 8.11拉到 0.99 还剩 6.35。通常的说法是 ΔE 到 5 以上就是一眼能看出来的色边。只有拉到 1.0 这一档才突然干净ΔE 一下掉到了 0.19。可文件也涨到了 438 482 字节是原图的 3.5 倍。为一张海报存 428 KB 的文件我那台小服务器的硬盘先不答应。1.0 为什么会一下子变好我去读了 JPEG 文件头里记着的采样因子才弄明白。0.99 及以下导出的 JPEG 全是 4:2:0 抽样颜色信息在横竖两个方向上各砍掉一半。到 1.0 才换成颜色一点不砍的 4:4:4。红字和底色的区别大半落在颜色上面颜色一砍字边就晕开了。在 Chromium 里一直往上调质量等于在已经砍过颜色的图上继续花钱。把这几档摆在一起算账就更清楚了。从 0.8 拉到 0.99 多花了 150 KB 却只让字边色差少了 1.76。反倒是我原来看不上的两个选项最干净。124 色的 PNG-8 是 48 481 字节WebP 无损是 49 432 字节。两个的色差都贴着零体积也比哪一档 JPEG 都小。这句话有个前提。它只对这种几种纯色加字的平面图成立换一类图就不一定了。我怕自己画的图太规整又从网上找了一张现成的 2026 年国庆放假通知模板来试。模板出自稿定设计尺寸 1242×2688原图 PNG 是 3 339 216 字节。质量这条线的方向和我那张海报一样。浏览器 JPEG 质量从 0.80 提到 0.99文件变成原来的 3.2 倍。「假期安排」这几个红字的字边色差只是从 6.56 落到 4.48。到 1.00 才换成 4:4:4这时文件是比原图 PNG 还大的 3 643 511 字节。PNG 这一头在这张图上却不占便宜。模板里有渐变、插画和灯笼。它存成 WebP 无损是 2 359 014 字节比 JPEG 0.9 大了 2.5 倍。这张是我拿那张模板在自己写的一个导出对比小页面上截的整屏。页面顶上选的是 JPEG、质量 0.99、放大 6 倍。上半块是原图。下半块是把导出的文件重新解码以后的同一块区域。放大的都是卡片上「10月8日返岗」那一行红字。导出后那块右上角写的 1.91 MB 和抽样 4:2:0 是页面自己从文件头里读出来的。要看的是笔画外沿。原图的红字边是齐的导出后每一笔外面都贴着一圈淡粉色的晕「日」和「岗」的横竖笔画边上最明显。这行字有 40 像素左右大差别得细看。模板日历上更小的农历字放大 6 倍以后在 JPEG 0.9 那份里能看出发暗发褐。我还想知道现成的工具碰到这张图会怎么处理。对照组我用的是图映 ImgInghttps://imging.cn/的压缩转换同一台 Mac 和同一个 Chromium 下全默认参数跑的全程也没看到上传请求。它默认根本没给我 JPEG。界面提示检测到图标或线稿以后直接走了 PNG-8结果是 124 色的 48 481 字节旁边标着省 62%。我又手动把下载格式切到 JPG 看看它会怎么说。它推荐的质量是 88出来 147 563 字节下面还跟着一行提醒说比原图大 17% 想更小可以换 WEBP。把滑杆拉到 100 出来的是 270 978 字节和我自己用 toBlob 0.99 导出的是同一个文件逐字节一样。也就是说在 Chromium 里它导出的 JPG 同样是 4:2:0。工具能做的是提前提醒你这张图别转 JPG转完以后的色边它也救不回来。省 62% 这个数也只是那张程序海报的结果。网上那张模板丢进去以后它判的是截图或界面。它默认走 WebP 画质 843.18 MB 变成 587.9 KB 标着省 82%。字边色差是 5.12和有损 WebP 在一个水平上。回头算账。一律转 JPEG 在照片上到底省不省钱我这次没测照片不好下结论。在这张红底海报上它是纯亏的。存储多占一截每次被访问还要多走一截流量。图还更难看。我那个站偶尔会有人传活动海报和带字的宣传图这部分一直在白白多花钱。测到 1.0 那档的时候手边那杯口粮茶已经凉透了。我现在的改法是转格式之前先判断图是哪一类。颜色少、大块纯色加字的图保留 PNG 或者减色成 PNG-8剩下的才转 JPEG。判断的门槛我还在调。照片那一侧我还没测过这条线定在哪我心里也没底。你的上传逻辑要是也写死了转 JPEG可以拿一张红底白字的图过一遍。先对比转出来的字节数和原图再放大到五六倍看字边有没有晕开。