素材做完了才发现问题：iOS 要 8 个尺寸、安卓要 5 个目录、网页还要 @2x @3x、桌面端再来个 .ico——同一张图得手动导出十几遍，还老是有几个尺寸忘了、命名写错。这一页把这件事一次做完：选一个规格包，剩下的它全出，每张都给实测体积和最终文件名，导出就是按目录分好的 ZIP。另外两件容易被忽略的事我们也做了：大幅缩小会自动逐级减半（直接缩会产生摩尔纹，这不是玄学，页面里给你实测数字），像素图放大走 nearest（默认插补会把像素画糊成一片）。全程浏览器本地处理，图片不上传服务器。
批量拖入 · 7 套规格包 · 等比留边/裁切填满 · 逐级减半防混叠 · 像素 nearest · 偶数对齐 · PNG/WebP/JPEG · 导出 ZIP / ICO
PNG / JPG / WebP，最多 6 张，每张都会出整套尺寸
行，但容易漏。iOS 上架要 8 个尺寸、安卓要 5 个目录、网页还要 @2x @3x，桌面端再来个 .ico——同一张图十几个文件，手动做必然有漏的、命名写错的、某个尺寸忘了换的。而它们是同一张源图、同一套参数，本来就该一次性算完。另外这里每档都是从原图重新算，不是拿上一档再缩放——后者会让 @3x 变成「@2x 再放大 1.5 倍」，糊两遍。
有用，但要看条件——我们把三种条件都实测了，不吹。canvas 缩放的本质是 box filter，一次缩小超过 2 倍就会跳着采样：一张 1px 黑白棋盘格直接缩到 1/12，采到的点不均匀，结果会留下一堆随机黑块白块（摩尔纹）；而每步只缩一半（512→256→128→64→…），每个像素都被平均过，结果才是均匀的灰。用 512×512 的 1px 棋盘格实测（理想结果应是一片均匀灰，标准差越接近 0 越好）：
| 条件 | 逐级减半 | 一步到位 | 结论 |
|---|---|---|---|
| 低质量档 + 非整数倍（512→40，12.8 倍） | 0 | 40.6 | 差距巨大，一步到位会糊成摩尔纹 |
| 高质量档 + 非整数倍（512→40） | 0 | 0 | 浏览器自己已经做了多级，两者一样 |
| 任意档 + 整数倍（512→64，8 倍） | 0 | 0 | box filter 完美平均，连低质量都不混叠 |
所以我们的结论是反直觉的：默认开着没坏处，但如果你用的是「平滑」档，关掉它能省时间，画质完全一样；只有在「低」质量档下它才真正必需。页面顶部的汇总条会按你当前的设置，把这两个数实时算给你看，并直接告诉你该开还是该关——不用记这张表。
因为默认缩放是插补：它会在原有像素之间「算」出新颜色，一个 8×8 的小人放大 4 倍就变成一片模糊的色块，像素画的硬边全没了。把「缩放算法」切成 像素（nearest） 就不一样了——它只复制原有像素，不制造新颜色。这个也能验证：示例那张 64×64 像素角色放大 3 倍后，用 nearest 得到的不同颜色数是 6 种 种，和原图 6 种 种完全一样；用平滑插补则是 329 种 种——多出来的全是插补造的。
@1x 就是「一倍图」。默认每张图以自己的原尺寸作为 @1x，@2x 就是两倍宽高。但你手上如果是一批原始尺寸参差的图（有 1024 的、有 300 的），按各自基准出来的 @2x 互相之间大小关系就乱了。这时把基准改成 「统一指定 @1x 宽度」（比如都按 512 算），它们才会按同一个尺子出，摆在一起才对得上。做完这步再去图标规整统一视觉分量，效果最好。
这里把常用的都做成规格包了，选一下就行：
| 规格包 | 会导出 | 文件怎么放 |
|---|---|---|
| Web / 小程序 @1x @2x @3x | 1 倍、2 倍、3 倍 | 平铺，文件名带 @2x 后缀 |
| Android mdpi → xxxhdpi | 1x / 1.5x / 2x / 3x / 4x | 自动分到 drawable-mdpi … drawable-xxxhdpi 目录 |
| iOS App 图标 | 40 / 58 / 60 / 80 / 87 / 120 / 180 / 1024 | 方形，默认按裁切填满（App 图标不接受透明边） |
| 小游戏常用 | 64 / 128 / 256 / 512 | 平铺，文件名带尺寸后缀 |
| 纹理 mipmap 链 | 从 2 的幂一路减半到 1 | 平铺，文件名带边长，引擎按顺序读 |
| ICO 图标 | 16 / 32 / 48 / 64 / 128 / 256 | 合成单个 .ico 文件 |
没有你要的就选「自定义倍率」，比如填 0.5, 1, 1.5, 2, 3。
.ico 其实只是一个容器：一个 6 字节的头 + 每档 16 字节的索引，后面接着每档的图像数据。很多在线工具在里面塞的是未压缩的 BMP——光 256 那一档就要 256×256×4 ≈ 262 KB。我们塞的是 PNG（Vista 之后的系统和主流看图软件都认），同一档只要 8.1 KB，整个多档 ICO 才 14.3 KB。还有个细节：索引里宽高各只有 1 个字节，256 存不下，规范约定用 0 表示 256——写错就会被识别成 0 尺寸打不开。
mipmap 是给 3D 纹理用的一套「从大到小」的图：物体远的时候用小的那张，就不会因为采样不足而闪烁。规范要求每一级是上一级的正好一半，所以边长必须是 2 的幂（512 / 256 / 128 …）。如果你的图是 600×600 这种非 2 的幂，工具会先向上对齐到 1024 再开始减半——这会带来轻微形变，所以做纹理时最好一开始就按 2 的幂出图。
三种情况会卡住：① 视频编码（H.264 等要求宽高都是偶数）；② 部分压缩纹理格式（ETC、PVRTC 要求边长是 4 的倍数甚至 2 的幂）；③ 某些老引擎和贴图工具会直接拒绝奇数尺寸。缩放算出来的尺寸经常是奇数（比如原图 333 宽出 @1.5x 得到 499.5），所以这里给了对齐选项，勾上就不会踩到。
免费，无水印、无需注册。缩放和编码都在浏览器本地用 canvas 完成，图片不经过任何服务器。
