URL.revokeObjectURL 调用后内存不立即释放，是因为浏览器需确认无 DOM/JS 引用且待事件循环空闲才回收；富文本编辑器中须在图片节点移出文档时及时 revoke，并防御性校验 URL 格式。
为什么 URL.revokeObjectURL 调用后仍可能内存不释放？
直接调用 URL.revokeObjectURL 并不能保证立即释放内存，尤其在富文本编辑器中反复创建/撤销 Blob URL 时。根本原因是：浏览器只在确认没有 DOM 引用、JS 变量引用、且下一次事件循环空闲时才真正回收底层 Blob 数据。常见现象是编辑器预览图片越来越多，performance.memory.usedJSHeapSize 持续上涨，但没报错——这不是泄漏，是延迟回收。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 确保调用
URL.revokeObjectURL前，该 URL 已从所有img.src、iframe.src、video.src等属性中移除（哪怕只是设为空字符串） - 避免在 Promise 回调或异步操作中“忘记”调用 revoke，比如上传成功后只更新 UI，却漏掉清理上一个预览的 URL
- 不要复用同一个
URL.createObjectURL(blob)返回值多次；每次新 blob 都应配对一次 revoke，旧 URL 不会自动失效
在富文本编辑器中安全绑定与解绑 Blob URL 的时机
典型场景：用户拖入图片 → 转为 Blob → 生成 URL → 插入 img 标签 → 编辑中删除该图片节点。关键不是“什么时候 revoke”，而是“谁负责 revoke”和“是否还有隐式引用”。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 在插入图片时，把生成的 URL 存进 DOM 节点的自定义属性：
img.dataset.blobUrl = url，而非仅存在闭包变量里 - 监听编辑器内容变化（如
input、DOMSubtreeModified或 MutationObserver），检测到该img被移出文档树时，立即调用URL.revokeObjectURL(img.dataset.blobUrl) - 如果使用 React/Vue，切勿只在组件
useEffect或beforeUnmount中 revoke —— 编辑器内容变动不触发组件重卸载，必须监听实际 DOM 移除事件
URL.revokeObjectURL 被忽略的兼容性与静默失败
该 API 在所有现代浏览器中都可用，但有两个容易被忽略的行为：一是传入非法参数（如 null、已 revoke 过的 URL、非 string）不会抛错，而是静默返回；二是 Safari 对 revoked URL 的后续访问行为更严格（可能触发 img.onerror，而 Chrome 仍显示缓存图像）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 加一层防御性判断：
if (typeof url === 'string' && url.startsWith('blob:')) { URL.revokeObjectURL(url); } - 不要依赖
revoke调用后的状态检查（无返回值，无事件）；改用定时采样performance.memory或 DevTools 的 Memory 面板观察趋势 - 测试时用
chrome://memory-internals（Chrome）或 Safari 的 “Develop > Show Web Inspector > Resources > Memory” 查看 blob 实例数，比看 JS 堆更准
替代方案：何时该放弃 Blob URL，改用 FileReader.readAsDataURL？
当编辑器内图片数量少（≤5）、尺寸小（单图 readAsDataURL 反而更可控：它不产生需手动管理的全局 URL，无 revoke 概念，GC 完全由 JS 引用决定。
实操建议：
立即学习“前端免费学习笔记（深入）”；
-
readAsDataURL输出 base64 字符串，体积比原始 Blob 大 ~33%，慎用于大图或批量导入 - 若需支持图片旋转/裁剪等二次处理，仍推荐 Blob +
createObjectURL，因为FileReader是一次性读取，无法重复解码 - 混合策略可行：小图用 data URL（免 revoke），大图走 Blob URL + MutationObserver 清理，通过文件 size 切换逻辑
