ImageMagick — 图像处理瑞士军刀
待复核ImageMagick 是一套命令行图像处理工具：把图片转格式、改尺寸、裁剪、合成、加字、查元信息，都可以用一行命令完成。
日常类比：它像后厨里的万能刀和案板。Photoshop 是坐在店里慢慢点菜，ImageMagick 是后厨收到 1000 张图后按同一张小票批量处理。
它的经典价值在三个 CLI 上最明显：
convert/magick：读入一张或一组图，输出另一张或一组图mogrify：对一批现有图片原地改造，适合批处理identify：不改图，只回答”这张图到底是什么”
ImageMagick 7 的统一入口是 magick，老文章里常见的 convert、mogrify、identify 在新写法里通常写成 magick ...、magick mogrify ...、magick identify ...。它在 GitHub 上约 12.7k stars，但影响力远大于 star 数，因为很多网站后端、CMS、脚本工具都曾把它当成默认图像管道。
不理解 ImageMagick，下面这些事会很难解释：
- 为什么网站上传头像后能自动生成 64、128、512 三种缩略图，而不是人工一张张改
- 为什么 PNG 转 JPEG 有时背景变黑：格式能力不同，透明通道可能被丢掉
- 为什么一张 30000x30000 的图片能把服务器拖慢：图像处理真正吃的是像素面积，不只是文件大小
- 为什么命令行工具仍然有生命力：它可以被 shell、CI、后端服务、定时任务稳定调用
ImageMagick 可以先抓住三件事：
-
输入图 → 操作 → 输出图：最基本形态是
magick input.jpg output.png。类比：把原材料放上案板，按顺序切、洗、装盘。 -
选项顺序很重要：
-resize、-strip、-quality这类选项会影响后面读写和处理。类比：先腌再烤，和先烤再腌，结果不是一回事。 -
批处理才是杀手锏：单张图可以用 GUI，几千张图就需要脚本。类比：一件衣服可以手洗，一整车布料必须进流水线。
从机制上看，ImageMagick 会先识别文件格式，把图像解成像素和元数据，再按命令里的操作修改像素，最后按输出后缀或显式格式重新写出。
这也是它强大的原因：JPEG、PNG、GIF、TIFF、PDF、SVG、WebP 都可以被放进同一条管道里处理。但这也是风险来源：不同格式的透明度、颜色配置、压缩方式并不等价。
案例 1：把用户上传图变成网页缩略图
Section titled “案例 1：把用户上传图变成网页缩略图”真实场景：用户上传手机照片，网站需要统一转成不会太大的 WebP 缩略图。
magick upload.jpg -auto-orient -thumbnail 800x800\> -strip thumb.webp逐部分解释：
upload.jpg是输入图，ImageMagick 会根据文件内容和后缀识别格式-auto-orient按 EXIF 方向旋正，避免手机竖拍图横着显示-thumbnail 800x800\>只缩小大图，不放大小图；反斜杠是避免 shell 把>当重定向-strip去掉 EXIF、ICC 之外的冗余元信息，常用于减小网页图片体积thumb.webp是输出图，后缀告诉 ImageMagick 写成 WebP
这个案例体现的是 convert / magick 的核心能力：输入一张图，经过一串操作，写出新图，不破坏原图。
案例 2：批量处理一整个文件夹的商品图
Section titled “案例 2：批量处理一整个文件夹的商品图”真实场景：运营给了一批 PNG 商品图，前端需要统一 256x256 内的 JPEG 预览图。
mkdir -p previewsmagick mogrify -path previews -format jpg -resize 256x256\> *.png逐部分解释：
mogrify适合批量处理文件列表，*.png会匹配当前目录所有 PNG-path previews把输出写到新目录，避免覆盖原始素材-format jpg把输出格式改成 JPEG，所以a.png会生成previews/a.jpg-resize 256x256\>表示只把过大的图塞进 256x256 盒子，小图保持原尺寸
这个案例体现的是 mogrify 的危险与价值：它一次能处理很多文件，所以必须先想清楚是否会覆盖原图。
案例 3：上线前检查图片尺寸和格式
Section titled “案例 3：上线前检查图片尺寸和格式”真实场景：构建脚本要拒绝超大图片，避免把 6000px 海报直接塞进移动端页面。
magick identify -format "%m %w %h %[colorspace]\n" hero.png可能输出：
PNG 2400 1600 sRGB逐部分解释：
identify只读图，不改图，适合做检查和诊断%m是格式，%w/%h是宽高，%[colorspace]是颜色空间- 脚本可以读取这一行，判断宽高是否超过团队约定
- 遇到损坏或不完整的图片时，
identify会返回错误，适合提前挡在发布前
这个案例体现的是 ImageMagick 不只是”修图”，也能做媒体文件的体检工具。
mogrify默认会覆盖原图：没加-path或没换-format时，批处理可能直接改掉唯一素材。-resize 800x800不是强制变成正方形：默认保持比例，只是放进 800x800 的盒子；强制拉伸要加!，但通常不推荐。- JPEG 不支持透明度：PNG 透明图转 JPEG 时，透明区域需要先指定背景，否则结果可能变黑或变白。
- 大图按像素吃内存：文件只有 5MB 不代表处理便宜，解开后可能是几百 MB 的像素缓存。
适用 vs 不适用场景
Section titled “适用 vs 不适用场景”适用：
- 网站后端自动生成缩略图、封面图、预览图
- 批量把设计素材转格式、改尺寸、去元数据
- CI 中检查图片尺寸、格式、颜色空间是否符合约定
- 需要把图像处理接进 shell、Makefile、Docker、定时任务
不适用：
- 需要人工精修和实时预览的设计工作，直接用 Photoshop、GIMP 或 Affinity 更合适
- 大规模高性能图片服务，通常会选择 libvips / sharp 这类更偏流式的方案
- 复杂视频处理，应该交给 ffmpeg；ImageMagick 更擅长静态图和图像序列
- 处理不可信上传文件但没有安全策略的公网服务，风险太高
历史小故事（可跳过）
Section titled “历史小故事（可跳过）”- 1987 年：John Cristy 在 DuPont 遇到一个实际问题：要把 24-bit 图像显示在只能同时显示 256 色的屏幕上。
- 1990 年：DuPont 同意放出相关工具，ImageMagick 发布到 Usenet 的
comp.archives，成为早期开源图像工具之一。 - 90 年代中期：ImageMagick 随 Linux 生态传播，
convert、identify这类命令开始进入很多人的脚本习惯。 - ImageMagick 6：Anthony Thyssen 推动命令行行为更有秩序，并写下大量 Examples of ImageMagick Usage。
- ImageMagick 7：统一入口变成
magick，内部像素通道和颜色空间支持继续扩展。
- 命令行图像处理的本质是管道：读入图片，按顺序变换，写出结果。
- 批处理是 ImageMagick 的主战场：单张图不稀奇，稳定处理一批图才是价值。
- 格式不是后缀这么简单：透明度、颜色空间、压缩方式都会影响最终结果。
- 媒体工具要同时关心质量、速度和安全：越靠近用户上传入口，越要限制资源和格式。
- 官方 README：ImageMagick/ImageMagick
- 命令行工具总览：Command-line Tools
magick示例：Command-line Tools: Convert- 批处理说明：Command-line Tools: Mogrify
- 图像信息检查：Command-line Tools: Identify
- sharp —— 现代 Node.js 图片处理常用方案，偏服务端性能