调用 URL.createObjectURL(blob) 会强引用 Blob，阻止其被垃圾回收；必须显式调用 URL.revokeObjectURL() 才能释放资源，FinalizationRegistry 无法可靠触发自动注销。
调用 `url.createobjecturl(blob)` 会强引用 blob，阻止其被垃圾回收；必须显式调用 `url.revokeobjecturl()` 才能释放资源，finalizationregistry 无法可靠触发自动注销。
在 Web 开发中，Blob 对象常用于处理二进制数据（如图片、音频、文件下载），而 URL.createObjectURL() 提供了一种高效生成临时 URL 的方式，供 <img>、<video></video> 或 fetch() 等使用。但一个关键且易被忽视的事实是：该 API 并非“弱绑定”，而是对 Blob 实施了强引用（strong reference）。
根据 W3C File API 规范，浏览器内部维护一个 blob URL store —— 一个全局映射表，将生成的 blob: URL 字符串关联到对应的 Blob 实例。只要该 URL 未被显式撤销（即未调用 URL.revokeObjectURL(url)），底层 Blob 就不会被垃圾回收，即使你的 JavaScript 代码中已没有任何变量持有对该 Blob 的引用。
例如，以下代码存在内存泄漏风险：
async function getImageBlobURL() {
const res = await fetch('/image.png');
const blob = await res.blob(); // ❌ 无变量引用 blob，但 URL.createObjectURL 仍持强引用
const url = URL.createObjectURL(blob);
return url; // ✅ 返回 url，但 blob 无法 GC
}
const url = await getImageBlobURL();
const img = new Image();
img.src = url; // 正常加载
document.body.append(img);
// ⚠️ 此时：img.src 持有 url，url 在 blob URL store 中持有 blob → blob 永远不被 GC！
你可能尝试用 FinalizationRegistry 实现“自动注销”，如下所示：
const registry = new FinalizationRegistry<string>(url => URL.revokeObjectURL(url));
export function getAutoRevokableBlobUrl(blob: Blob) {
const url = URL.createObjectURL(blob);
registry.register(blob, url); // ❌ 错误假设：blob 能被及时 GC
return url;
}</string>
该方案不可靠，原因有三：
-
Blob 不会被及时 GC：只要
blob:URL 存在于 blob URL store 中，规范要求浏览器必须保持 Blob 可访问——因此registry的回调永远不会执行（或极延迟，甚至永不触发）； - FinalizationRegistry 不保证执行时机：它仅在对象确实已被 GC 后可能调用回调，而此处 Blob 根本不满足 GC 条件；
-
注册目标错误：应注册 URL 字符串 或 持有 URL 的 DOM 元素（如
<img>），而非 Blob 本身——因为真正“拥有”该 URL 生命周期的是浏览器环境，不是 JS 引用。
✅ 正确做法：手动管理 URL 生命周期，遵循“谁创建，谁销毁”原则：
// 推荐：封装为可撤销的资源句柄
export class BlobUrlHandle {
private url: string;
constructor(blob: Blob) {
this.url = URL.createObjectURL(blob);
}
get href(): string {
return this.url;
}
revoke(): void {
if (this.url) {
URL.revokeObjectURL(this.url);
this.url = '';
}
}
}
// 使用示例
const blob = new Blob(['hello'], { type: 'text/plain' });
const handle = new BlobUrlHandle(blob);
const a = document.createElement('a');
a.href = handle.href;
a.download = 'hello.txt';
a.textContent = 'Download';
document.body.append(a);
// ✅ 清理：在不再需要时显式撤销（如元素移除、组件卸载时）
function cleanup() {
a.remove();
handle.revoke(); // 关键：主动释放
}
? 最佳实践总结：
- 始终配对使用
createObjectURL/revokeObjectURL； - 在 DOM 元素卸载（如
connectedCallback/disconnectedCallback）、React 组件useEffect cleanup、或MutationObserver检测到元素移除时，及时调用revokeObjectURL； - 避免长期持有
blob:URL（尤其在单页应用中），防止内存持续增长； - 可借助
WeakRef+FinalizationRegistry监控 DOM 元素 的销毁（如注册<img>），再在回调中撤销 URL —— 但这仍是辅助手段，不能替代显式清理。
记住：Web 平台的资源管理是明确的、非自动的。对 Blob 和 object URL 的尊重，就是对用户内存和性能的负责。
