北京
几个月前，一位开发者需要为Shopify店铺转换400张产品图片，从JPG格式转为WebP格式。他试了市面上常见的在线转换工具，结果都不太满意。
这些工具的流程几乎一样：把文件上传到服务器、排队等待、再下载一个ZIP压缩包。免费版有的会加 watermark（水印），有的限制只能转10张，想多转就得付费。对于400张图片来说，这个流程相当痛苦。
但最让他介意的，是上传这一步。这些是产品照片，他不想让它们留在别人的服务器上，哪怕只是临时存放。
于是他干脆自己动手，做了一个叫 BatchSet 的批量图片转换工具。这个工具完全在浏览器里运行，不上传、不注册、无水印。用户把图片拖进去，本地完成转换，然后下载ZIP文件。
浏览器端的图片处理能力
现在的浏览器能做的图片处理工作，比很多人想象中要多。BatchSet 的核心流程是这样的：用户拖入文件，FileReader 读取为 ArrayBuffer，createImageBitmap 在 Web Worker 中解码，OffscreenCanvas 绘制并编码为目标格式，JSZip 打包，最后自动下载ZIP。
关键的第一步是解码。大多数人还在用 new Image() 或者 canvas.drawImage() 配合源图片，这种方式能用，但跑在主线程上，会阻塞界面。
createImageBitmap 不一样。它在主线程之外解码图片，返回一个 ImageBitmap 对象，可以直接绘制到任何 canvas 上，不需要重新解码。
速度方面，一张典型的2MB产品照片，解码只需要20-40毫秒。真正的优势在于它不阻塞UI线程，所以即使处理几百张图片，进度条也能保持流畅。
编码与并行处理
解码完成后，需要编码为目标格式。如果要输出WebP、JPG或PNG，把 bitmap 绘制到 OffscreenCanvas 上，然后调用 convertToBlob 即可。
OffscreenCanvas 可以在 Web Worker 内部工作，所以繁重的编码任务——尤其是大图或高质量输出——不会让标签页卡死。
真正的性能提升来自并行处理。BatchSet 使用 navigator.hardwareConcurrency 获取逻辑CPU核心数，为每个核心创建一个 Worker，图片以轮询方式分发给各个 Worker。在一台8核的现代笔记本上，这意味着8张图片可以同时处理。
纯客户端方案的边界
这种"纯客户端"方案有它的优势，也有它的局限。优势很明显：隐私安全，图片不出设备；没有服务器成本；没有上传下载的等待时间。
局限也同样存在。浏览器能处理的图片格式和编码参数有限，某些高级功能（比如HEIC格式转换）在部分浏览器中并不支持。另外，处理超大图片或大量图片时，内存占用会成为一个问题。
但就批量转换这个场景而言，纯浏览器方案已经足够实用。400张产品图片，本地转换，直接下载，整个过程不需要把任何一张图交给第三方服务器。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
