本地图片预览，通常两种写法都能出图：FileReader.readAsDataURL(file)，或者 URL.createObjectURL(file)。单张小图看不出区别，等到批量选图、频繁切换和全屏预览连在一起，问题就变成了：哪些数据被保留，谁负责释放，异步结果回来时页面还需不需要它？
我维护的图片处理项目图片猫（PicCat）使用 Vue。梳理当前代码时，可以看到批量选图已经使用 Blob URL，智能抠图的原图读取仍使用 Data URL，全屏预览则有独立的 Blob URL 管理。这几条真实路径，正好可以用来讨论如何选择，而不是给两种 API 排名。
项目背景：图片猫 PicCat.cn
1 先分清地址 内容和像素
本文所说的"Base64 预览"，准确说是带 Base64 载荷的 Data URL，例如 data:image/png;base64,...。Base64 是编码方式，Data URL 才是交给 img.src 的完整字符串；并非所有 Data URL 都使用 Base64。
Blob URL 是浏览器为 Blob 或 File 注册的临时资源地址。它把"地址"与"文件内容"分开，创建地址不需要先把完整图片转成 Base64 文本。地址短，不代表底层文件、解码缓存和画布都不占资源。12
对于纯本地预览，我会优先选 Blob URL；只有确实需要把内容作为文本交给下一环节时，才承担 Base64 转换成本。这个选择的前提是：同时把 URL 的生命周期管理好。
2 约三分之一的膨胀 不等于总内存结论
标准带填充 Base64 每3个输入字节编码为4个字符，载荷长度为 4 × ceil(N / 3)。这是编码长度公式，不是浏览器进程内存公式。3
|----------------|----------------------|-------------------------|
| 项目 | 计算或估算 | 能说明什么 |
| 原始文件 | 6 MiB = 6,291,456 字节 | 文件大小，不等于解码后的大小 |
| Base64 载荷 | 8,388,608 字符 | 约增加三分之一；尚未加 Data URL 前缀 |
| 6000 × 4000 图像 | 24,000,000 个像素 | 两种预览路径都需要处理这些像素 |
| 单份 RGBA 8位缓冲 | 宽 × 高 × 4 ≈ 91.6 MiB | 理论像素缓冲估算，不是实测内存 |
不能把 Base64 字符数机械乘以2，再宣称这是 JavaScript 的实际占用。引擎对字符串可能采用不同存储形式，也可能出现共享、拼接或临时副本；底层文件数据、图像解码与 GPU 资源又不一定完整体现在 JS heap 里。
两条路径的成本分别在哪里
Data URL 路径需要读取文件并生成完整文本，img 再从这段文本取得资源。readAsDataURL 是异步读取接口，不能因此说整段流程"完全不影响主线程"；创建大字符串、后续状态更新和图片解码仍然有成本。
Blob URL 路径省去了预览前的完整 Base64 编码，但 img 加载资源和解码仍是后续工作。只计时 createObjectURL() 的返回速度，再拿它与 FileReader 的完成事件比较，会把"建立引用"和"读取编码完成"混成同一指标。
|-----------|----------------|---------------------|
| 决策点 | Blob URL | Base64 Data URL |
| 本地文件与批量预览 | 通常优先使用 | 有额外完整文本表示 |
| 需要字符串内嵌内容 | 地址本身不包含图片 | 适合明确要求文本载荷的场景 |
| 释放方式 | 撤销自有映射，并移除其他引用 | 移除字符串与使用者的引用 |
| 持久化或交给服务端 | 不能把临时地址当远程文件地址 | 可以传文本，但要确认大小和协议 |
上传文件也不天然需要 Base64。接口接受 FormData 或二进制时，可以继续传 File/Blob；不要为了预览先编码，再为了上传解码回来。这里是接口设计建议，不代表项目所有上传接口都采用同一种协议。
3 批量预览 关键是成对管理创建和释放
当前 useBatchFiles.ts 由 BatchResize.vue 和 BatchImageCompress.vue 等调用。接收文件经过筛选和预处理后，文件本身放入 selectedFiles，预览地址放入 previewUrls。以下只摘录创建部分，省略格式校验、SVG 转换、数量限制及路径记录。
项目代码摘录 · useBatchFiles.ts，循环中省略无关语句
for (const file of acceptedPreparedFiles) {
selectedFiles.value.push(file);
const url = URL.createObjectURL(file);
previewUrls.value.push(url);
imageDimensions.value.push('');
// 下文还有相对路径记录和异步尺寸读取
}
创建 URL 只是第一步。当前代码在移除单张时撤销对应地址，在清空列表时撤销全部地址，并在组件卸载时执行 cleanup。autoRevokeUrls 默认为 true；批量尺寸与压缩两个调用点未关闭它。
项目代码原文 · useBatchFiles.ts，卸载清理部分
const cleanup = () => {
if (autoRevokeUrls) {
previewUrls.value.forEach((url) => URL.revokeObjectURL(url));
}
};
onUnmounted(cleanup);
这里要区分两件事：revokeObjectURL 撤销的是浏览器中的资源映射；selectedFiles 中的 File、DOM 中的图片、Canvas 像素等仍需各自结束使用。当前 clearAll 还会清空相关数组，而 cleanup 本身主要负责撤销 URL。不能看到一行 revoke 就断言所有内存立即归零。
不要把图片加载完成 当作用户使用结束
如果 URL 仍供页面展示、右键保存或放大预览使用，img.onload 之后立即撤销可能破坏后续交互。对展示图片，应在移除、替换或所属组件销毁时释放；如果 Image 只是一次性读取尺寸或绘制像素的临时对象，则可以在工作完成、且不存在其他使用者后释放。1
同一个 Blob 多次调用 createObjectURL 会得到不同地址，每个映射都需要管理。模板求值或重复渲染时顺手创建 URL，会让创建次数脱离文件数量；把创建放在明确的文件接收流程里更容易审计。
临时地址不能当持久化数据
Blob URL 刷新后不能用于恢复图片，也不能发给服务端当作可下载文件。SSR 阶段不要执行依赖 document、Image 的浏览器逻辑；预览操作应放在客户端生命周期或事件中。
4 全屏预览 为什么要区分自有和借用地址
一个预览弹层可能接收父组件的图片地址，也可能自己从 Blob 创建地址。当前 useFullscreenImagePreview.ts 用 ownedObjectUrl 单独记录自己创建的 URL：openUrl 借用外部地址，openBlob 创建并接管地址。关闭弹层不应该撤销父组件仍在使用的图片。
项目代码原文 · useFullscreenImagePreview.ts，所有权记录
let ownedObjectUrl: string | null = null;
let requestId = 0;
const releaseOwnedUrl = () => {
if (!ownedObjectUrl) return;
URL.revokeObjectURL(ownedObjectUrl);
ownedObjectUrl = null;
};
项目代码原文 · 两种打开入口；其余返回值和监听器未展示
const openUrl = (url: string, alt = '图片放大预览') => {
requestId += 1;
releaseOwnedUrl();
previewUrl.value = url;
previewAlt.value = alt;
isOpen.value = true;
};
const openBlob = (blob: Blob, alt = '图片放大预览') => {
requestId += 1;
releaseOwnedUrl();
ownedObjectUrl = URL.createObjectURL(blob);
previewUrl.value = ownedObjectUrl;
previewAlt.value = alt;
isOpen.value = true;
};
这个划分比"只要字符串以 blob: 开头就释放"更准确。blob: 只能识别地址种类，不能证明当前组件拥有它。借用地址的创建者仍须保证：弹层使用期间地址有效。
异步生成结果 也有生命周期
openCanvas 在开始时递增 requestId，等待 toBlob 回调后再核对序号。如果期间又打开了另一张图，旧结果返回 false，不创建新的对象 URL，也不覆盖当前预览。已经打开的弹层关闭时，以及组件卸载时，代码也会递增序号并释放自有地址。
这不是取消编码任务：旧 toBlob 仍可能继续工作。序号校验解决的是"过期结果不接管页面状态"；限制同时编码的任务数，是另一层峰值资源控制。
格式与安全限制仍然存在：两种地址都不能让浏览器解码原本不支持的图片格式。CSP 应核对 img-src 对 blob:、data: 的允许范围；跨域图片污染 Canvas 后，换成 toBlob 也不能绕过导出限制。4
5 预览像素预算 往往比地址长度更关键
当前全屏预览对 Canvas 快照同时设置最长边2560和约400万像素预算。只有超出预算时才创建缩小的临时画布，然后用 toBlob 输出 PNG。原始编辑画布不在这里缩小。
项目代码原文 · openCanvas 中的缩放比例计算
const maxPreviewEdge = 2560;
const maxPreviewPixels = 4_000_000;
const sourceWidth = Math.max(1, canvas.width);
const sourceHeight = Math.max(1, canvas.height);
const previewRatio = Math.min(
1,
maxPreviewEdge / sourceWidth,
maxPreviewEdge / sourceHeight,
Math.sqrt(maxPreviewPixels / (sourceWidth * sourceHeight))
);
使用面积约束时要开平方：宽和高都乘以 r，面积会乘以 r²。代码取两个边长约束、一个像素约束和1的最小值，因此不会为了预览放大小图；最终尺寸使用 Math.round，像素总数可能因取整略高于设定值，所以它不是严格的硬上限。
toBlob 后，代码在 finally 中把临时画布的宽高重置为0，再丢弃空 Blob 或过期请求。重置帮助结束临时像素存储的使用，但浏览器何时回收、原始画布与 GPU 缓存是否仍驻留，不能由这两行赋值保证。
因此，这条路径的价值是避免完整 Base64 文本，并限制额外预览快照的尺寸。它没有解决原图首次解码的峰值，也没有给整个编辑器设置总内存上限。toBlob 本身仍需要编码时间，异步回调也不等于零成本。4
6 当前仍有需要补齐的边界
智能抠图原图仍走 Data URL
SmartCutout.vue 的 processFile 目前先读取 Data URL，交给 originalImage 解码，随后设置画布尺寸并更新 imageUrl。下面是根据原函数整理的教学简化片段；省略了文件校验、遮罩重置、状态事件和重绘，不能单独复制运行。
教学简化代码 · 依据 SmartCutout.vue 的 processFile
const reader = new FileReader();
reader.onload = (e) => {
const result = e.target?.result as string;
originalImage.onload = () => {
currentFile.value = file;
imageUrl.value = result;
// 原函数还会设置画布尺寸、重置状态并重绘
};
originalImage.src = result;
};
reader.readAsDataURL(file);
该组件卸载时对 imageUrl 调用 revokeObjectURL，但在上述路径中它保存的是 Data URL。这个调用不会释放 Base64 字符串。字符串能否被回收，取决于相关状态、Image 对象与闭包等是否仍然可达；仅凭这处调用，也不能断言已经发生持续泄漏。
尺寸回调不能长期相信数组下标
useBatchFiles 的尺寸读取先记住 currentIndex，再在 img.onload 里写入 imageDimensionscurrentIndex。如果加载期间删除了更早的文件，下标可能已经改变。当前片段没有为这次写入校验文件身份，也没有 img.onerror 分支。这是源码可见的风险，本文没有把它写成已复现的用户故障。
建议改进片段 · 回调时重新定位当前 URL，尚未写入项目
img.onload = () => {
const index = previewUrls.value.indexOf(url);
if (index < 0) return;
imageDimensions.valueindex =
`{img.naturalWidth} × {img.naturalHeight}`;
};
这段建议只处理被删除或位置变化的回写；完整接入还应补充错误状态、事件解绑和卸载失效标记。规模变大时，可改用带稳定 id 的文件记录，避免维护多组平行数组。
全屏预览也有一个待补强的取消边界：close 只把 isOpen 设为 false。如果首次 openCanvas 仍在等待、弹层本来就是关闭状态，watch 不会因为 false → false 而触发失效。若要支持"生成前取消"，建议在 close 内直接递增 requestId 并清理状态，再验证它与监听器的配合；当前实现不能被描述为覆盖所有取消情况。
7 怎样验证 才不会把猜测当成优化结果
本文数值来自公式计算，已核对编码长度与快照尺寸；没有开展浏览器性能基准或真实内存对照实验。下面是建议验收方法，不是已经通过的测试记录。建议代码也尚未集成到业务中。
建议验收清单
|----------|-----------------------------------------------------------------|
| 检查项 | 建议方法与判断依据 |
| 预览耗时 | 同一组文件、同一设备与显示尺寸；分别记录地址准备、图片解码完成和实际显示。重复采样，不只计时 URL 创建。 |
| 资源是否持续累积 | 重复选图→移除→清空→离开页面；记录基线、峰值及稳定后的趋势。结合进程内存和堆快照，避免只看 JS heap。 |
| 释放与所有权 | 记录 create/revoke 次数及尚在使用的地址；关闭借用地址的弹层后，父视图仍应可用。计数平衡不等于没有其他内存驻留。 |
| 异步与失败路径 | 快速连续切换、加载中删除、生成中关闭、组件卸载、损坏文件、toBlob 返回 null；过期结果不得覆盖新状态。 |
Chrome DevTools 的内存排查文档建议结合任务管理器与堆分析观察不同资源。测试时不要把大文件、Data URL 或图片对象持续输出到控制台，以免调试工具自身保留引用。强制 GC 后的单次数字也不能代表实际使用峰值。5
我的选择顺序是：先判断是否真的需要文本载荷，再为预览设置像素和并发预算，最后明确每个 URL 的创建者、使用者与释放时机。Blob URL 解决表示与生命周期问题；控制解码和画布规模，才能继续处理大图预览的资源压力。
源码与参考资料
源码位置均相对 webClientVue/src：composables/useBatchFiles.ts、composables/useFullscreenImagePreview.ts、components/SmartCutout.vue；调用点为 components/batch/BatchResize.vue 与 BatchImageCompress.vue。本文描述的是核对时的工作区实现，不据此推定线上部署版本。