前端 createObjectURL 预览文件后什么时候 revoke

前端用 URL.createObjectURL(file) 预览本地文件时，revokeObjectURL 的正确时机不是“创建后马上释放”，而是等最后一个消费者用完这条对象 URL。图片通常等 load 或失败回调后清理；替换预览时先释放旧 URL；组件销毁时清理仍挂在状态里的 URL。下载链接则要等点击流程结束，不能在设置 href 后立刻撤销。

createObjectURL 不是永久地址，先看清它连接了什么

Blob 表示不可变的原始数据，File 在此基础上增加了文件名等信息。URL.createObjectURL() 接收 Blob、File 或 MediaSource，返回一条对象 URL；它可以给 img、video 或下载链接使用，但不是上传到服务器后的永久 URL。

因此，下面这种写法有隐患：

const url = URL.createObjectURL(file);
preview.src = url;
URL.revokeObjectURL(url); // 错误：图片还没有完成读取

撤销后，浏览器不再需要保留这条对象 URL 的引用。MDN 对 revokeObjectURL() 的描述也是“完成使用后释放”，而不是创建后立即释放。

什么时候 revoke 才不会把正在使用的预览掐掉

可以把清理点归纳为四类。图片预览最稳妥的是在 load 或 error 后清理；如果页面还要让用户右键保存或重复读取，就把 URL 留到预览节点被替换或移除。多次选择文件时，新 URL 覆盖旧 URL 之前，旧 URL 是最明确的清理对象。

用一个可追踪的预览函数处理替换和失败分支

把 URL 保存在闭包或组件状态里，清理动作就不会散落在多个事件处理器中。下面的实现只保留一张预览图：新文件到来时先让旧图失去使用关系，再创建新 URL；新图加载成功或失败都释放当前引用。

function bindImagePreview(input, image) {
  let activeUrl = null;

  const release = () => {
    if (!activeUrl) return;
    URL.revokeObjectURL(activeUrl); // 只释放当前仍被追踪的引用
    activeUrl = null;
  };

  const onChange = () => {
    release(); // 新文件替换旧预览前，先清理旧 URL
    const file = input.files?.[0];
    if (!file) {
      image.removeAttribute('src'); // 清空选择时同步清空画面
      return;
    }

    const url = URL.createObjectURL(file);
    activeUrl = url;
    image.onload = image.onerror = () => {
      if (activeUrl === url) release(); // 防止旧回调误清理新 URL
    };
    image.src = url;
  };

  input.addEventListener('change', onChange);
  return () => {
    input.removeEventListener('change', onChange); // 组件卸载时解除监听
    release(); // 释放尚未完成消费的当前 URL
  };
}

这里的比较 activeUrl === url 很关键。用户快速连续选择文件时，旧图片的 error 或 load 可能晚于新图片回调到达；如果回调无条件清理，就可能把新预览使用的 URL 一并撤销。

下载和多文件列表要把“最后一次使用”算清楚

下载场景通常是创建临时 a 元素、触发点击、移除元素。释放可以放在点击之后，但如果浏览器或业务代码还会继续读取这条 URL，就应该延后到下载动作确认结束。多文件预览则用数组或 Map 保存 URL 与文件的对应关系，删除一项时只撤销那一项，不能用一个全局变量覆盖所有引用。

function disposePreviewMap(previews) {
  for (const url of previews.values()) {
    URL.revokeObjectURL(url); // 列表销毁时逐条释放对象 URL
  }
  previews.clear(); // 释放后删除映射，避免再次误用
}

还要注意，revokeObjectURL 对无效或已经撤销的对象 URL 不会产生额外效果，但这不是重复调用的理由；可追踪的生命周期更容易排查预览突然失效和长期占用的问题。对象 URL 也不是 Service Worker 可用的通用缓存方案，相关生命周期限制要按运行环境单独处理。

常见问题

图片触发 load 后可以立刻 revoke 吗？

如果图片只需要完成当前预览，通常可以；如果后续还要重新读取、下载或交给其他消费者，就应继续保留到最后一次使用完成。

revokeObjectURL 调用两次会报错吗？

对已经撤销或无效的对象 URL，浏览器不会因为这次调用抛出错误，但业务代码仍应维护唯一的当前引用。

为什么只清空 img.src 还不够？

清空 DOM 属性不等于释放通过 createObjectURL 建立的引用。只要代码还保存着这条对象 URL，就应该在生命周期结束时显式调用 revokeObjectURL。

判断标准可以压缩成一句话：谁最后使用对象 URL，谁决定释放边界。先记录每次创建的 URL，再在加载结束、替换、卸载或下载完成的明确节点清理，预览就不会在“释放太早”和“永不释放”之间来回摆动。