消失的图片：别让 blob: URL 成为你系统里的“内存幻象”

在构建富文本编辑器、文件上传预览或即时通讯系统时，我们习惯于使用 URL.createObjectURL(file) 来实现秒级预览。

但你是否遇到过这种诡异的情况：图片在上传时显示正常，但切换了一下页面路由，或者刷新了一下会话，图片就变成了裂图，控制台无情地抛出 net::ERR_FILE_NOT_FOUND？

这背后的根因在于对 Blob URL 生命周期 的误解。

一、 核心误区：blob: URL 并不是持久资源

很多开发者潜意识里把 blob:http://localhost:3000/xxx 当作一个普通的 URL，认为只要字符串在，资源就在。

真相是：

• blob: URL 是一个指向内存的指针。
• 它仅在创建它的当前文档（Document）生命周期内有效。
• 一旦页面刷新、关闭，或者单页应用（SPA）中触发了特定的状态重置，该内存映射就会被浏览器回收。

二、 历史会话的“防腐”设计

如果你在做聊天记录回放、草稿箱回显，千万不要依赖 File 对象或 blob: URL。

1. 临时态 vs 持久态

• 临时态（File/Blob）： 仅用于“当前会话”的即时预览。
• 持久态（后端 URL）： 只有服务器返回的 http/https 链接才是真正可靠的资源标识。

2. 回退链设计（Fallback Chain）

在工程实践中，为了保证极致的加载体验和稳定性，建议采用以下加载优先级：

1. 持久化 URL： 优先加载后端存储地址。
2. 本地 Blob（备用）： 如果是刚上传未刷新的状态，尝试从内存读取。
3. 占位图/错误状态： 最终的保底方案，避免页面流出难看的“裂图”。

三、 排障的“指纹”证据

当你看到以下组合时，几乎可以 100% 确定是生命周期问题：

• 报错信息： net::ERR_FILE_NOT_FOUND
• 协议前缀： blob:
• 触发场景： 页面路由切换、组件销毁重建、或在 history 状态中恢复数据。

四、 revokeObjectURL 的正确姿势

内存管理是双刃剑。手动调用 URL.revokeObjectURL() 是防止内存泄漏的好习惯，但必须严格划清边界：

避坑指南： > 在回收前必须进行类型校验。不要对正常的 http 链接或普通的字符串执行回收操作，否则可能误伤其他正常的图片渲染。

JavaScript

// 推荐的防御式回收
const clearResource = (url) => {
  if (url && url.startsWith('blob:')) {
    URL.revokeObjectURL(url);
  }
};

五、 总结：从“能跑就行”到“工程健壮”

从“能预览”到“能稳定回放”，差的就是对资源生命周期的敬畏。

1. 认清本质： Blob 是内存映射，不是磁盘文件。
2. 状态分离： 历史数据必须依赖持久化地址，不要把 File 对象带入持久化存储。
3. 链路防御： 用“回退链”思想解决竞态条件下的资源失效。

把“卡死”变成“可控”，把“裂图”变成“优雅回退”，这就是工程化的价值。