浏览器内跑完整图像引擎 (ImageMagick WASM)：把 C++ 图像处理库 ImageMagick 用 Emscripten 编译成 WebAssembly,让浏览器本地完成压缩/格式转换/缩放/gif 编辑等重处理。toolonline.net 的 13 个 image 工具就是它的落地案例——图片从头到尾不出本机。

工作机制(三层)

图片工具 JS (13 个, ES Module)
   │  import { execute } from magickApi.js   ← ① API 包装层(TS, Apache-2.0)
   ▼
Web Worker 后台线程
   │  importScripts(magick.js)               ← ② Emscripten 胶水(142KB)
   ▼
instantiateStreaming(magick.wasm)            ← ③ ImageMagick 二进制(4.2MB)
  • magickApi.js：TypeScript 写的封装,暴露 execute({inputFiles, commands}),内部用 Worker + importScripts 加载引擎,locateFile 让 wasm 从同目录加载
  • 虚拟文件系统：FS.mkdir('/pictures') 建内存磁盘,输入图片写进去,执行字符串命令行 'convert in.png -resize 50% out.jpg',再取回 outputFiles
  • 工具调用 = 拼 ImageMagick 命令行参数(混淆 JS 里能直接看到 'convert -quality ' 这类字符串)

识别方法

  • 工具描述写"在本地浏览器中进行""不用把图片上传" = 前端 WASM 处理
  • lib/ 下出现 .wasm 文件 + API 包装 JS + Worker/importScripts 模式
  • 看 Network:处理时无图片上传请求(反之若有点按钮后有大 body POST,是后端处理)

商业/架构启示

  • 重算力下沉到客户端：服务器只发静态文件 + 轻 API,压缩/转换全在用户浏览器,省服务器算力和带宽,CDN 成本为主
  • 隐私是卖点：本地处理天然"图片不被服务器获取"
  • 产品分层引流：网页版故意只开部分格式(如 compress 只认 jpg/jpeg/gif),完整格式留给桌面 app,形成下载导流
  • 同思路生态:ffmpeg.wasm(视频)、sqlite wasm(数据库)、ocr 引擎等

常见坑

  • wasm MIME：server 必须返回 application/wasm,否则 instantiateStreaming 报错降级到 ArrayBuffer(能跑但非最优)
  • 缺 wasm 文件：只下载 API 包装 JS、漏掉 magick.js + magick.wasm,页面加载正常但一处理就挂——这类"点按钮才崩"的缺陷,加载级验证测不出来,必须功能级测试
  • 静态 import{execute} 使这些工具是 ES Module,反混淆工具(webcrack)对其语法失败

相关

本文归档于个人知识库 · 领域：CS & AI · 模块：04 Project_CS_AI/Web