一张 10MB 的照片，为什么能吃掉浏览器近 100MB 内存？

做在线图片压缩工具时，我遇到过一个很反直觉的现象：

用户上传的照片明明只有 10MB，页面还没有开始压缩，浏览器内存却已经上涨了几十甚至上百 MB。多选几张高清照片后，页面开始卡顿，预览变成空白，严重时标签页直接失去响应。

第一反应通常是：代码存在内存泄漏。

但很多时候，代码还没来得及泄漏，图片解码本身就已经占用了大量内存。

这篇文章结合我开发 Pixel Slim 的过程，拆解浏览器批量处理图片时最容易忽略的内存问题。

一、文件大小不等于图片占用的内存

我们在文件管理器中看到的 10MB，是 JPEG、WebP 等格式压缩后的文件体积。

浏览器想要显示或编辑图片，必须先把它解码成像素。常见的 RGBA 像素中，每个像素需要 4 个字节：

内存占用 ≈ 图片宽度 × 图片高度 × 4

以一张 6000 × 4000 的手机照片为例：

6000 × 4000 × 4
= 96,000,000 Bytes
≈ 91.6 MB

也就是说，一张磁盘中只有 10MB 左右的照片，解码后仅像素数据就可能占用接近 100MB。

如果用户一次选择 10 张类似照片，理论像素数据就可能接近 1GB。这还没有计算 Canvas、预览图和导出结果。

图片上传组件处理的不是几个 10MB 文件，而可能是一批解码后接近 100MB 的像素缓冲区。

二、一张图片可能同时存在多个副本

在一个看似普通的图片压缩页面里，同一张图片可能以多种形式同时存在：

原始 File
↓
Object URL
↓
Image / ImageBitmap
↓
预览 Canvas
↓
导出 Canvas
↓
压缩后的 Blob

其中，File 和 Blob 保存的是编码后的文件数据，而 ImageBitmap 和 Canvas 背后的缓冲区保存的是解码后的像素数据。

如果为了方便，把原图、预览图、导出结果和历史状态全部保存在 React state 中，一张图片就可能产生多个生命周期不同的副本。

更容易误判的是：Canvas 和图片解码产生的部分内存不一定完整显示在 JavaScript Heap 中。你查看堆快照时可能觉得一切正常，但浏览器进程占用仍在增长。

三、Promise.all 可能是批量处理的第一颗雷

批量压缩最自然的写法是：

const results = await Promise.all(
files.map((file) => compressImage(file))
);

代码很简洁，但它会尝试同时解码和处理所有图片。

当用户选择几十张高清照片时，问题不再是“能不能更快”，而是浏览器有没有足够内存让它们同时运行。

最保守的方案是串行处理：

async function processImages(files: File[]) {
const results: Blob[] = [];

for (const file of files) {
const result = await compressImage(file);
results.push(result);
}

return results;
}

串行任务稳定，但图片较多时速度偏慢。更实用的方案是限制并发，例如每次只处理两张：

async function runWithLimit<T, R>(
items: T[],
limit: number,
task: (item: T) => Promise<R>
) {
const results: R[] = new Array(items.length);
let nextIndex = 0;

async function worker() {
while (nextIndex < items.length) {
const currentIndex = nextIndex++;
results[currentIndex] = await task(items[currentIndex]);
}
}

const workers = Array.from(
{ length: Math.min(limit, items.length) },
() => worker()
);

await Promise.all(workers);
return results;
}

调用时只需要指定并发上限：

const results = await runWithLimit(
files,
2,
compressImage
);

并发数量没有绝对标准，需要根据图片尺寸、设备性能和处理算法动态权衡。手机端通常应该比桌面端更保守。

四、处理完成不代表资源已经释放

即使函数已经执行结束，浏览器也不一定会立即释放相关资源。

1. 释放 Object URL

使用 URL.createObjectURL() 创建预览地址后，应在不再使用时主动撤销：

const previewUrl = URL.createObjectURL(file);

try {
await renderPreview(previewUrl);
} finally {
URL.revokeObjectURL(previewUrl);
}

2. 关闭 ImageBitmap

ImageBitmap 提供了明确的释放方法：

const bitmap = await createImageBitmap(file);

try {
drawBitmap(bitmap);
} finally {
bitmap.close();
}

3. 清空临时 Canvas

临时 Canvas 使用完成后，可以重置尺寸，帮助浏览器释放像素缓冲区：

canvas.width = 0;
canvas.height = 0;

4. 移除不再需要的引用

如果 React state 中仍然保存着旧的 Blob、预览地址或图片对象，垃圾回收器就不能释放它们。

组件卸载或图片被删除时，需要同步清理相关资源，而不是只把图片卡片从页面上隐藏。

五、预览不应该使用原始分辨率

如果页面中的预览区域只有 600px 宽，就没有必要为它长期保存一张 6000px 宽的预览 Canvas。

可以根据容器尺寸生成低分辨率预览：

function calculatePreviewSize(
width: number,
height: number,
maximumEdge: number
) {
const scale = Math.min(
maximumEdge / Math.max(width, height),
1
);

return {
width: Math.round(width * scale),
height: Math.round(height * scale),
};
}

编辑阶段使用低分辨率 Canvas，可以明显降低内存占用，让拖动、缩放和裁剪保持流畅。

用户点击下载时，再根据相同的裁剪参数创建高清导出 Canvas。导出完成后立即释放，不让高清画布长期留在页面中。

低分辨率 Canvas：负责交互预览
高清 Canvas：只在导出时临时创建

两块 Canvas 不需要拥有相同尺寸，只需要读取同一套归一化编辑状态。

六、不要把所有结果都转成 Base64

一些图片工具会使用 FileReader.readAsDataURL()，把图片转换成 Base64 后保存在 state 中。

这种方式使用方便，但 Base64 的体积通常比原始二进制数据增加约三分之一。长字符串还会增加 JavaScript 内存和序列化成本。

对于本地预览，更适合使用 Object URL：

const previewUrl = URL.createObjectURL(file);

对于下载结果，可以直接保留 Blob，需要下载时再临时创建 URL：

function downloadBlob(blob: Blob, fileName: string) {
const url = URL.createObjectURL(blob);
const anchor = document.createElement("a");

anchor.href = url;
anchor.download = fileName;
anchor.click();

URL.revokeObjectURL(url);
}

七、失败状态也必须隔离

批量任务中，一张图片解码失败，不应该让其他图片全部失败。

每张图片应当拥有独立状态：

type ImageTaskStatus =
| "waiting"
| "processing"
| "completed"
| "failed";

这样可以支持：

• 显示每张图片的处理进度；
• 单独重试失败任务；
• 下载已经成功的结果；
• 取消等待中的任务；
• 避免一个异常中断整个队列。

这不只是交互体验问题，也能防止用户因为页面没有反馈而重复上传、刷新或连续点击。

八、我在实际项目中的最终取舍

开发 Pixel Slim 时，我最终采用了这些策略：

这些优化没有改变图片压缩的核心算法，却直接影响了页面能否稳定处理多张高清图片。

写在最后

前端图片处理最危险的误区，是把“文件体积”当成“内存占用”。

一张 10MB 的照片，解码后可能接近 100MB；同时处理十张，就可能把一个普通网页变成内存压力测试。

所以，可靠的批量图片工具不仅要考虑压缩率，还要处理：

• 解码后的真实内存；
• 并发任务数量；
• 预览与导出分辨率；
• Blob、Object URL 和 Canvas 的生命周期；
• 移动设备的性能边界；
• 单张图片失败后的任务隔离。

我把这些实践应用到了 Pixel Slim，目前支持批量压缩、尺寸修改、拖动裁剪、自由拼图、长图拼接、透明背景和局部图片修复。

无需注册，手机和电脑都可以直接使用：

Pixel Slim：https://image.997728.xyz

如果你正在开发图片上传、头像裁剪或内容管理系统，建议亲自测试一次多张高清照片同时上传。

很多内存问题，只有在真实图片面前才会暴露出来。