Blob 对象与 Blob URL 的生命周期关系详解-js教程-PHP中文网

Blob 对象与 Blob URL 的生命周期关系详解

URL.createObjectURL() 会隐式持有 Blob 的强引用，阻止其被垃圾回收，直到显式调用 URL.revokeObjectURL()；FinalizationRegistry 无法可靠触发自动回收，因此“自动撤销 URL”的方案不可行。

`url.createobjecturl()` 会隐式持有 blob 的强引用，阻止其被垃圾回收，直到显式调用 `url.revokeobjecturl()`；finalizationregistry 无法可靠触发自动回收，因此“自动撤销 url”的方案不可行。

在 Web 开发中，Blob 对象常用于处理二进制资源（如图片、音频、文件下载），而 URL.createObjectURL(blob) 是将其暴露为可访问 URL 的关键方法。但一个常见误区是认为：只要不再持有对 Blob 的 JavaScript 引用，它就会被垃圾回收（GC），进而自动释放关联的 blob URL。这是不正确的。

根据 W3C File API 规范，createObjectURL 会在浏览器内部维护一个 blob URL store —— 即一个从生成的 URL 字符串到对应 Blob 实例的映射表。该映射构成对 Blob 的强引用（strong reference），等效于在 JS 中显式持有变量引用。因此，即使函数作用域结束、blob 变量超出作用域、且无其他 JS 引用，该 Blob 仍不会被 GC。

例如以下代码：

async function getImageBlobURL() {
  const res = await fetch('/image.png');
  const blob = await res.blob(); // ❌ 此处 blob 不会被 GC
  const url = URL.createObjectURL(blob);
  return url; // 返回 url 后，blob 仍在内存中！
}

调用后，blob 持续存活，占用内存，且 url 保持有效。若未手动撤销，将导致内存泄漏——尤其在频繁创建图片预览或上传临时预览时风险显著。

那么，FinalizationRegistry 能否作为“自动撤销”方案？答案是否定的。你提供的 getAutoRevokableBlobUrl 尝试注册 blob 到 FinalizationRegistry 并在终结回调中调用 URL.revokeObjectURL(url)，但问题在于：只要 blob URL store 中存在映射，Blob 就永远不会进入可终结状态（finalizable）。FinalizationRegistry 仅在对象完全不可达（即无任何强引用，包括内部映射）时才可能触发回调，而 createObjectURL 建立的内部引用恰恰阻止了这一点。实测中，该回调几乎永不会执行。

✅ 正确做法是：显式管理生命周期，遵循“谁创建，谁撤销”原则：

在不再需要 URL 时（如 <img> 元素卸载、组件销毁、用户切换资源），立即调用 URL.revokeObjectURL(url)；
推荐结合 DOM 生命周期（如 MutationObserver、IntersectionObserver 或框架的 useEffect/onUnmounted）自动撤销；
若需复用 Blob，可缓存 Blob 实例并共享 URL，避免重复调用 createObjectURL。

示例（安全实践）：

function createImageFromBlob(blob: Blob): Promise<htmlimageelement> {
  return new Promise((resolve, reject) => {
    const img = new Image();
    const url = URL.createObjectURL(blob);

    img.onload = () => {
      URL.revokeObjectURL(url); // ✅ 及时释放
      resolve(img);
    };
    img.onerror = () => {
      URL.revokeObjectURL(url); // ✅ 错误时也释放
      reject(new Error('Failed to load image'));
    };

    img.src = url;
  });
}</htmlimageelement>

⚠️ 注意事项：