SVG 转 PNG 踩坑记录，重新理解矢量图转位图

很多工具看起来只是一个按钮，真正实现起来，细节远比想象中多。

最近在开发 toolgarden.xyz 的图片工具时，我踩了一个很典型的坑：SVG 转 PNG 后图片变糊了。

最后虽然解决了，但也让我重新理解了「矢量图转位图」这件事。

为什么做 ToolGarden

主要是因为平时开发总会遇到各种零散的小需求：JSON 格式化、图片压缩、图片格式转换、PDF 处理、二维码生成……这些需求都不复杂，但每次都要打开不同的网站。有的广告很多，有的要上传文件，有的功能残缺，还有的下次想用时已经找不到了。

干脆自己做了一个工具站，把自己常用的需求集中起来，尽量做到：

• 浏览器本地处理，保护隐私
• 静态部署，打开即用
• 不依赖后端，响应速度快

在制作图片工具的过程中，一开始实现了 JPG、PNG、WebP、GIF、BMP、SVG、AVIF 等格式之间的互相转换，本以为只是一个普通功能，结果在 SVG 转 PNG 上踩了坑。

---

为什么 SVG 转出来会变糊？

最开始采用的是最常见的方案：

Image/File -> HTMLImageElement -> Canvas -> PNG / JPG / WebP

对于 JPG、PNG、WebP 这类位图，这套流程没问题。图片本身已有固定像素尺寸，Canvas 按原尺寸绘制再导出即可。

但 SVG 不一样，SVG 是矢量图，没有固定的像素网格。浏览器之所以能把它显示得很清晰，是因为会根据当前显示尺寸实时渲染。

而一旦绘制到 Canvas，就必须先完成一次栅格化（Rasterization） ——把矢量图转换成固定像素的位图，真正决定最终清晰度的，就是这一步。

最开始直接用浏览器解析出来的 naturalWidth 和 naturalHeight 作为 Canvas 尺寸，结果很多 SVG 都被栅格成了偏小的分辨率。浏览器里看着锐利的图标，导出 PNG 后边缘发虚，放大后尤其明显。 也就是说：PNG 并没有变糊，真正变糊的是 SVG 在进入 Canvas 的那一刻。

为什么放大以后还是不清晰？

发现图片变糊之后，第一反应很自然：那就放大一点再导出。

然而效果并没有改善。

原因很好理解：如果 SVG 已经先以低分辨率渲染成了一张位图，再去放大它，本质上只是把一张已经丢失细节的图片放大。缺失的信息不会重新出现，只能依赖插值算法去猜测。

后来尝试了另一种方案：先渲染成更大的图片，再缩小回目标尺寸。

这次思路终于接近正确答案。高分辨率渲染后再降采样（Supersampling），本来就是图像处理中常见的抗锯齿方式。先保留更多细节，再缩小到目标尺寸，理论上可以获得更平滑、更锐利的边缘。

但新的问题又出现了。

Canvas 默认的 drawImage() 缩放虽然方便，但它主要追求的是速度和兼容性，不是最高质量的重采样。对于 SVG 中大量存在的文字、图标、细线和斜边，经常会出现：

• 边缘发灰
• 锯齿明显
• 细线断裂
• 文字轮廓变软

也就是说，仅仅提高渲染分辨率还不够，最终缩小时采用什么算法，同样会直接影响图片质量。

最后我找到了解决方案： Pica，Pica 是一个专门用于浏览器图片缩放的高质量重采样库。相比 Canvas 默认的 drawImage()，它采用了更高质量的缩放滤镜，并针对浏览器环境做了大量优化，在缩小时能更好地保留边缘细节，减少锯齿和模糊，还支持适度锐化，让图标、文字和线条看起来更干净。

换句话说，它解决的不是 「放大」 的问题，而是 「缩小」 的问题。

真正清晰的流程应该是：SVG 先以足够高的分辨率完成栅格化，再使用高质量的重采样算法缩小到最终尺寸。

Pica 并不会凭空增加图片细节，它做的是高质量降采样（Resampling） 。在缩小图片时，它会综合多个源像素计算目标像素，而不是简单取样，因此能更好地保留边缘、线条和文字细节，减少混叠（Aliasing）和锯齿。

最终的解决方案

最后把 SVG 的处理逻辑从普通图片转换中单独进行了拆分，整个流程变成了：

解析 SVG 尺寸 -> 计算目标输出尺寸（默认 3 倍）->  高质量缩放 -> 导出 PNG / JPG / WebP

1. 正确解析 SVG 的真实尺寸

首先读取 SVG 文本，解析根节点上的 width、height、viewBox。如果没有显式指定宽高，就根据 viewBox 推导。如果使用的是 pt、cm、mm、in 等单位，也统一换算成像素。这样才能得到真正的逻辑尺寸。

2. 默认导出 3 倍分辨率

例如：

• SVG：400 × 300
• 默认输出 PNG：1200 × 900

这样生成的图片，无论是在普通屏幕还是 Retina 屏幕上，都更加清晰，也更适合作为网页素材、文档插图或设计资源继续使用。

3. 小尺寸 SVG 先进行超采样

对于尺寸很小的 SVG，不会直接按 3 倍渲染，而是先创建一个更大的中间画布，这样浏览器在第一次栅格化时就能保留更多细节，最后再缩小到真正需要的输出尺寸。

4. 使用高质量降采样

最后一步没有继续使用 Canvas 默认缩放，而是用了 Pica。相比直接 drawImage，它提供了更高质量的重采样算法，并支持适度锐化。尤其是在处理图标、文字、曲线、斜边、Logo 时，边缘明显更加锐利，也不会出现之前那种发灰的问题。

5. 给渲染设置合理上限

高清渲染并不是越大越好，如果无限放大，一个复杂 SVG 很容易让浏览器占满内存。因此增加了一些限制，例如最长边限制、最大像素数量限制、Canvas 尺寸限制。这样既保证了清晰度，也避免页面因为超大 SVG 而卡死。

这次踩坑的一些总结

这次bug和修复让我意识到，图片转换并没有想象中那么简单，还需要了解一些图形学的基础知识。

SVG 的关键不是导出，而是栅格化

SVG 是矢量图，PNG、JPG、WebP 都是位图。真正决定清晰度的，不是导出格式，而是矢量图第一次转换成位图时使用了多大的像素尺寸。如果这一步做错了，后面再怎么放大，都无法恢复细节。

SVG 应该单独处理

JPG、PNG、WebP 天生就有固定像素，SVG 则需要根据 width、height 和 viewBox 推导尺寸。它们虽然都是图片，但处理逻辑完全不同。

缩放算法同样重要

很多人容易忽略这一点。高分辨率渲染只是第一步，最终降采样时使用什么算法，同样会直接影响图片边缘的质量。对于图片工具来说，默认的 Canvas 缩放已经很难满足高质量需求。

不同格式有不同的处理重点

不同格式之间并不是简单改一个后缀：

• PNG 要保留透明通道
• JPG 不支持透明，需要填充背景色
• WebP 需要平衡质量、体积以及浏览器兼容性

真正做好图片转换，需要理解每一种格式背后的特性。

浏览器本地处理也需要考虑性能

toolgarden.xyz 的图片工具全部运行在浏览器中，这样既保护隐私，也方便静态部署。但与此同时，也必须考虑 Canvas 内存占用、超大图片处理、Worker 支持、模型加载、浏览器性能差异。否则，一个简单的图片转换工具，也可能轻易拖垮页面。

写在最后

这次 SVG 转 PNG 的修复，本质上并不是多加几个参数，而是重新理解了矢量图如何变成位图这个过程。

只有先确定合适的栅格化尺寸，再配合高质量的重采样算法，最终才能得到真正清晰的 PNG。

很多工具看起来只是一个按钮。真正把它做好之后才发现，决定体验的往往不是功能本身，而是那些用户看不见的细节,而这些细节，才是真正区分「能用」和「好用」的地方。